Editing article

Title

Summary

<div class="block-paragraph">Open-source software is used throughout the technology industry to help developers build software tools, apps, and services. While developers building with open-source software can (and often do) benefit greatly from the work of others, they should also conduct appropriate due diligence to protect against <a href="https://www.dni.gov/files/NCSC/documents/supplychain/Software_Supply_Chain_Attacks.pdf" target="_blank">software supply chain attacks</a>.With an increasing focus on managing open-source software supply chain risk, both Citi and Google strive to apply more rigor across risk mitigation, especially while choosing known and trusted suppliers where open source components are sourced from.<h3 data-block-key="8pjtn">Key open source attack vectors</h3></div>
<div class="block-image_full_width">

</div>
 </div>

</div>
<div class="block-paragraph_advanced">The diagram above highlights key open source attack vectors.  We can divide the common software supply chain security attacks into five main types:
<ol>
<li style="list-style-type: none;">
<ol>
<li role="presentation">Attacks at runtime leveraging vulnerabilities in the code  </li>
<li role="presentation">Attacks on the repositories, tooling and processes </li>
<li role="presentation">Attacks on the integrity of the artifacts as they progress through the pipeline</li>
<li role="presentation">Attacks on the primary open source dependencies that customers applications leverage</li>
<li role="presentation">Attacks throughout the inherited transitive dependency chain of the open source packages </li>
</ol>
</li>
</ol>
Application security experts have seen their work increase and get harder as these attacks have increased in recent years. Open-source components often include and depend on the functionality of other open-source components in order to function. These components can have two types of dependencies: direct and transitive. 
Generally, the interactions work like this: The application makes an initial call to a direct dependency. If the direct dependency requires any outside components for it to function, those outside components are the application’s transitive dependencies.
These types of dependencies are notoriously difficult to remediate. This is because they are not readily accessible to the developer. Their code base resides with their maintainers, rendering the application entirely dependent upon their work. If the maintainer of one of these transitive dependencies releases a fix, the amount of time before it makes its way up the supply chain to impact your direct dependency could be a while. 
Thus, the management of vulnerabilities needs to be extended to the full transitive dependency chain as this is where <a href="https://www.forbes.com/sites/forbestechcouncil/2023/05/26/the-hidden-risk-lurking-in-the-software-supply-chain-transitive-open-source-dependencies/?sh=5e66dc87512f" rel="noopener" target="_blank">95% of the vulnerabilities</a> are found. Maintaining a regular upgrade and patching process for your software development lifecycle (SDLC) tooling is now a must; as is upgrading the security of both your repositories and processes combined with active security testing of each. 
Tamper-evident provenance and signing can increase confidence in the ability to maintain artifact integrity throughout the pipeline. And mapping and understanding the full transitive dependency chain of all external components and depending on only known and trusted providers for these components becomes a required condition. 
<a href="https://www.cisa.gov/sites/default/files/2023-10/Fact_Sheet_Improving_OSS_in_OT_ICS_508c.pdf" rel="noopener" target="_blank">Recent guidance from CISA</a> and other government agencies supports the focus on appropriately selecting and testing open source software ahead of ingestion from a trusted source. While some organizations load built software artifacts directly from public package repositories, others with a more restrictive security risk appetite will require more stringent security controls requiring the use of curated open-source software providers. 
They may opt to only leverage open-source software they themselves have built from source, although this would be prohibitively expensive for most. But if they chose to use a curated third party, what checks must they look for before delegating that critical authority?
There are three main criteria to evaluate a curated OSS vendor:
1. High level of security maturity
A trusted supplier must demonstrate a high level of security maturity. Common areas of focus are to examine the security hygiene of the supplier in particular. Look for details of the vulnerability management culture and ability to quickly keep up to date with patching within the organisation. They should also have a well trained team, prepared to quickly address any incidents and a regular penetration testing team, continuously validating the security posture of the organisation. 
The trusted supplier should be able to demonstrate the security of their own underlying foundational infrastructure. Check that they:
<ol>
<li style="list-style-type: none;">
<ol>
<li>Have an up-to-date inventory of their own external dependencies.  </li>
<li>Demonstrate knowledge and control of all ingest points.  </li>
<li>Leverage a single production build service so that they can maintain a singular logical control point. </li>
<li>Meet best practice standards for managing their infrastructure including:</li>
</ol>
</li>
</ol>
<ul>
<li style="list-style-type: none;">
<ul>
<li style="list-style-type: none;">
<ul>
<li aria-level="1" style="list-style-type: disc; vertical-align: baseline;">
Well designed separation of duties and IAM control
</li>
<li aria-level="1" style="list-style-type: disc; vertical-align: baseline;">
Built-in organizational policy and guard rails to secure Zero Trust network design
</li>
<li aria-level="1" style="list-style-type: disc; vertical-align: baseline;">
Automated and regular patching with associated evidence
</li>
<li aria-level="1" style="list-style-type: disc; vertical-align: baseline;">
Support for these posture controls with complementary continuous threat detection with detection, logging and monitoring systems.
</li>
<li aria-level="1" style="list-style-type: disc; vertical-align: baseline;">
Bonus points if they operate with "everything as code" and with hermetic, reproducible and verifiable builts.      
</li>
</ul>
</li>
</ul>
</li>
</ul>
2. High level of internal SDLC security
The security of the SDLC used within the trusted supplier must be extremely high, particularly around the control plane of the SDLC and the components that interact with the source code to build the end product. Each system must be heavily secured and vetted to ensure any changes to the software is reviewed, audited, and requires multi-party approvals before progressing to the next stage or deployment. Strong authentication and authorisation policies must be in place to ensure that only highly trusted individuals could ever build, or change the vendor infrastructure. 
The SDLC security also needs to extend to the beginning of the ingestion of the source code material into the facility and to any code or functionality used within the control plane of the system itself.
3. Effective insider threat program
As the trusted supplier is a high value target, there will be the potential for an insider threat as an attack vector.Therefore, the curated vendor would be expected to have an active and effective insider threat program. This personnel vetting approach should also extend to ensuring the location of all staff are within approved proximity and not outsourced. 
<h3>Trust but verify</h3>
It is also important that the trusted supplier provide supporting evidence and insights. This evidence includes:
<ol>
<li role="presentation">Checkable attestations on infrastructure security and processes via third party certifications and/or your own independent audit.  </li>
<li role="presentation">Checkable attestations for the security posture and processes for their SDLC against a standard framework like SLSA or SSDF.   </li>
<li role="presentation">Cryptographic signatures on the served packages and any associated accompanying metadata so that you can verify source and distribution integrity.</li>
</ol>
The actual relevance and security risk of an issue in a package is the combination of
inherent criticality of in isolation, the context it's used in, the environmental conditions in which its deployed, any external compensating controls, and decreased or increased risk in the environment. The figure below shows the interrelationship and interaction between vulnerabilities and threats in the application and those from the underlying infrastructure.</div>
<div class="block-image_full_width">

</div>
 </div>

</div>
<div class="block-paragraph_advanced">4. Enhanced security and risk metadata that should accompany each served package to increase your understanding and insights to both the inherent component risk of the code or artifact as well as how that risk can change in context of your specific application and environment. Key metadata can include:  
<ul>
<li aria-level="1" style="list-style-type: disc; vertical-align: baseline;">
Standard SBOM with SCA insights - vulnerabilities, licensing info, fully mapped transitive dependencies and associated vulnerability and licensing risk.  
</li>
<li aria-level="1" style="list-style-type: disc; vertical-align: baseline;">
VEX statements for how the inherited vulnerabilities from transitive dependencies affect the primary package being served. 
</li>
<li aria-level="1" style="list-style-type: disc; vertical-align: baseline;">
Any related threat intelligence specific to the package, use case, or your organization.
</li>
</ul>
The ability of the supplier to provide this type of enhanced data reinforces the evidence that they have achieved a high level of security and that the components they serve represent assured and more trustable ingredients you can employ with greater confidence.
<h3>Better control and balancing benefits of open source components</h3>
Leveraging open source components is critical to developer velocity, quality and accelerating innovation and execution. Applying these recommendations and requirements can enable you to better control and balance the benefits of using open source components with the potential risk of introducing targetable weak points in your SDLC and ultimately reduce your risk and exposure.
Google Cloud’s <a href="https://cloud.google.com/security/products/assured-open-source-software">Assured Open Source Software</a> (Assured OSS) service for Java and Python ecosystems gives any organization that uses open source software the opportunity to leverage the security and experience Google applies to open source dependencies by incorporating the same OSS packages that Google secures and uses into their own developer workflows. 
Learn more about <a href="https://cloud.google.com/security/products/assured-open-source-software">Assured Open Source Software</a>, enable Assured OSS through our <a href="https://developers.google.com/assured-oss?utm_source=blog&amp;utm_medium=referral#get-started" rel="noopener" target="_blank">self-serve onboarding</a> form, use the metadata API to list available Python and Java packages and determine which Assured OSS packages you want to use.</div>

Content

Author

Link

Published date

Image url

Feed url

Guid

Hidden blurb

--- !ruby/object:Feedjira::Parser::RSSEntry
published: 2024-03-26 16:00:00.000000000 Z
entry_id: !ruby/object:Feedjira::Parser::GloballyUniqueIdentifier
 guid: https://cloud.google.com/blog/products/identity-security/how-to-choose-a-known-trusted-supplier-for-open-source-software/
title: How to choose a known, trusted supplier for open source software
categories:
- Open Source
- Partners
- Security & Identity
summary: "<div class=\"block-paragraph\">Open-source software
 is used throughout the technology industry to help developers build software tools,
 apps, and services. While developers building with open-source software can (and
 often do) benefit greatly from the work of others, they should also conduct appropriate
 due diligence to protect against <a href=\"https://www.dni.gov/files/NCSC/documents/supplychain/Software_Supply_Chain_Attacks.pdf\"
 target=\"_blank\">software supply chain attacks</a>.With
 an increasing focus on managing open-source software supply chain risk, both Citi
 and Google strive to apply more rigor across risk mitigation, especially while choosing
 known and trusted suppliers where open source components are sourced from.<h3
 data-block-key=\"8pjtn\">Key open source attack vectors</h3></div>\n<div
 class=\"block-image_full_width\">\n\n\n\n\n\n\n \n <div class=\"article-module
 h-c-page\">\n <div class=\"h-c-grid\">\n \n\n <figure class=\"article-image--large\n
 \ \n \n h-c-grid__col\n h-c-grid__col--6 h-c-grid__col--offset-3\n
 \ \n \n \"\n >\n\n \n \n \n <img\n
 \ src=\"https://storage.googleapis.com/gweb-cloudblog-publish/images/Key_open_source_attack_vectors.max-1000x1000.png\"\n
 \ \n alt=\"Key open source attack vectors\">\n \n </a>\n
 \ \n </figure>\n\n \n </div>\n </div>\n \n\n\n\n\n</div>\n<div
 class=\"block-paragraph_advanced\">The
 diagram above highlights key open source attack vectors.  We can divide the common
 software supply chain security attacks into five main types:\n<ol>\n<li
 style=\"list-style-type: none;\">\n<ol>\n<li role=\"presentation\">Attacks at runtime leveraging vulnerabilities in the code  </li>\n<li
 role=\"presentation\">Attacks on the repositories,
 tooling and processes </li>\n<li role=\"presentation\">Attacks on the integrity of the artifacts as they progress through the
 pipeline</li>\n<li role=\"presentation\">Attacks
 on the primary open source dependencies that customers applications leverage</li>\n<li
 role=\"presentation\">Attacks throughout
 the inherited transitive dependency chain of the open source packages </li>\n</ol>\n</li>\n</ol>\nApplication security experts have seen their
 work increase and get harder as these attacks have increased in recent years. Open-source
 components often include and depend on the functionality of other open-source components
 in order to function. These components can have two types of dependencies: direct
 and transitive. \nGenerally,
 the interactions work like this: The application makes an initial call to a direct
 dependency. If the direct dependency requires any outside components for it to function,
 those outside components are the application’s transitive dependencies.\nThese types of dependencies are notoriously
 difficult to remediate. This is because they are not readily accessible to the developer.
 Their code base resides with their maintainers, rendering the application entirely
 dependent upon their work. If the maintainer of one of these transitive dependencies
 releases a fix, the amount of time before it makes its way up the supply chain to
 impact your direct dependency could be a while. \nThus, the management of vulnerabilities needs to be extended to the
 full transitive dependency chain as this is where <a href=\"https://www.forbes.com/sites/forbestechcouncil/2023/05/26/the-hidden-risk-lurking-in-the-software-supply-chain-transitive-open-source-dependencies/?sh=5e66dc87512f\"
 rel=\"noopener\" target=\"_blank\">95% of the vulnerabilities</a>
 are found. Maintaining a regular upgrade and patching process for your software
 development lifecycle (SDLC) tooling is now a must; as is upgrading the security
 of both your repositories and processes combined with active security testing of
 each. \nTamper-evident provenance
 and signing can increase confidence in the ability to maintain artifact integrity
 throughout the pipeline. And mapping and understanding the full transitive dependency
 chain of all external components and depending on only known and trusted providers
 for these components becomes a required condition. \n<a href=\"https://www.cisa.gov/sites/default/files/2023-10/Fact_Sheet_Improving_OSS_in_OT_ICS_508c.pdf\"
 rel=\"noopener\" target=\"_blank\">Recent guidance from CISA</a>
 and other government agencies supports the focus on appropriately selecting and
 testing open source software ahead of ingestion from a trusted source. While some
 organizations load built software artifacts directly from public package repositories,
 others with a more restrictive security risk appetite will require more stringent
 security controls requiring the use of curated open-source software providers. \nThey may opt to only leverage open-source software
 they themselves have built from source, although this would be prohibitively expensive
 for most. But if they chose to use a curated third party, what checks must they
 look for before delegating that critical authority?\nThere are three main criteria to evaluate a curated OSS vendor:\n1. High level of security maturity\nA trusted supplier must demonstrate a high level
 of security maturity. Common areas of focus are to examine the security hygiene
 of the supplier in particular. Look for details of the vulnerability management
 culture and ability to quickly keep up to date with patching within the organisation.
 They should also have a well trained team, prepared to quickly address any incidents
 and a regular penetration testing team, continuously validating the security posture
 of the organisation. \nThe
 trusted supplier should be able to demonstrate the security of their own underlying
 foundational infrastructure. Check that they:\n<ol>\n<li style=\"list-style-type:
 none;\">\n<ol>\n<li>Have an up-to-date
 inventory of their own external dependencies.  </li>\n<li>Demonstrate knowledge and control of all ingest points.  </li>\n<li>Leverage a single production build service so
 that they can maintain a singular logical control point. </li>\n<li>Meet best practice standards for managing their
 infrastructure including:</li>\n</ol>\n</li>\n</ol>\n<ul>\n<li style=\"list-style-type:
 none;\">\n<ul>\n<li style=\"list-style-type: none;\">\n<ul>\n<li aria-level=\"1\"
 style=\"list-style-type: disc; vertical-align: baseline;\">\nWell designed separation of duties and IAM control\n</li>\n<li
 aria-level=\"1\" style=\"list-style-type: disc; vertical-align: baseline;\">\nBuilt-in organizational
 policy and guard rails to secure Zero Trust network design\n</li>\n<li
 aria-level=\"1\" style=\"list-style-type: disc; vertical-align: baseline;\">\nAutomated and regular
 patching with associated evidence\n</li>\n<li aria-level=\"1\" style=\"list-style-type:
 disc; vertical-align: baseline;\">\nSupport for these posture controls with complementary continuous threat
 detection with detection, logging and monitoring systems.\n</li>\n<li
 aria-level=\"1\" style=\"list-style-type: disc; vertical-align: baseline;\">\nBonus points if
 they operate with \"everything as code\" and with hermetic, reproducible and verifiable
 builts.      \n</li>\n</ul>\n</li>\n</ul>\n</li>\n</ul>\n2. High
 level of internal SDLC security\nThe
 security of the SDLC used within the trusted supplier must be extremely high, particularly
 around the control plane of the SDLC and the components that interact with the source
 code to build the end product. Each system must be heavily secured and vetted to
 ensure any changes to the software is reviewed, audited, and requires multi-party
 approvals before progressing to the next stage or deployment. Strong authentication
 and authorisation policies must be in place to ensure that only highly trusted individuals
 could ever build, or change the vendor infrastructure. \nThe SDLC security also needs to extend to the beginning of the ingestion
 of the source code material into the facility and to any code or functionality used
 within the control plane of the system itself.\n3. Effective
 insider threat program\nAs
 the trusted supplier is a high value target, there will be the potential for an
 insider threat as an attack vector.Therefore, the curated vendor would be expected
 to have an active and effective insider threat program. This personnel vetting approach
 should also extend to ensuring the location of all staff are within approved proximity
 and not outsourced. \n<h3>Trust
 but verify</h3>\nIt is also
 important that the trusted supplier provide supporting evidence and insights. This
 evidence includes:\n<ol>\n<li role=\"presentation\">Checkable attestations on infrastructure security and processes via
 third party certifications and/or your own independent audit.  </li>\n<li
 role=\"presentation\">Checkable attestations
 for the security posture and processes for their SDLC against a standard framework
 like SLSA or SSDF.   </li>\n<li role=\"presentation\">Cryptographic signatures on the served packages and any associated accompanying
 metadata so that you can verify source and distribution integrity.</li>\n</ol>\nThe actual relevance and security risk of an
 issue in a package is the combination of\ninherent criticality of in isolation, the context it's used in, the
 environmental conditions in which its deployed, any external compensating controls,
 and decreased or increased risk in the environment. The figure below shows the interrelationship
 and interaction between vulnerabilities and threats in the application and those
 from the underlying infrastructure.</div>\n<div class=\"block-image_full_width\">\n\n\n\n\n\n\n
 \ \n <div class=\"article-module h-c-page\">\n <div class=\"h-c-grid\">\n
 \ \n\n <figure class=\"article-image--large\n \n \n h-c-grid__col\n
 \ h-c-grid__col--6 h-c-grid__col--offset-3\n \n \n \"\n
 \ >\n\n \n \n \n <img\n src=\"https://storage.googleapis.com/gweb-cloudblog-publish/images/End_to_end_risk_diagram.max-1000x1000.png\"\n
 \ \n alt=\"End to end risk diagram\">\n \n </a>\n \n
 \ </figure>\n\n \n </div>\n </div>\n \n\n\n\n\n</div>\n<div class=\"block-paragraph_advanced\">4. Enhanced security
 and risk metadata that should accompany each served package to increase your understanding
 and insights to both the inherent component risk of the code or artifact as well
 as how that risk can change in context of your specific application and environment.
 Key metadata can include:  \n<ul>\n<li aria-level=\"1\" style=\"list-style-type:
 disc; vertical-align: baseline;\">\nStandard SBOM with SCA insights - vulnerabilities, licensing info, fully
 mapped transitive dependencies and associated vulnerability and licensing risk.  \n</li>\n<li
 aria-level=\"1\" style=\"list-style-type: disc; vertical-align: baseline;\">\nVEX statements for
 how the inherited vulnerabilities from transitive dependencies affect the primary
 package being served. \n</li>\n<li aria-level=\"1\" style=\"list-style-type:
 disc; vertical-align: baseline;\">\nAny related threat intelligence specific to the package, use case, or
 your organization.\n</li>\n</ul>\nThe
 ability of the supplier to provide this type of enhanced data reinforces the evidence
 that they have achieved a high level of security and that the components they serve
 represent assured and more trustable ingredients you can employ with greater confidence.\n<h3>Better control and balancing benefits of open
 source components</h3>\nLeveraging
 open source components is critical to developer velocity, quality and accelerating
 innovation and execution. Applying these recommendations and requirements can enable
 you to better control and balance the benefits of using open source components with
 the potential risk of introducing targetable weak points in your SDLC and ultimately
 reduce your risk and exposure.\nGoogle
 Cloud’s <a href=\"https://cloud.google.com/security/products/assured-open-source-software\">Assured Open Source
 Software</a> (Assured OSS) service
 for Java and Python ecosystems gives any organization that uses open source software
 the opportunity to leverage the security and experience Google applies to open source
 dependencies by incorporating the same OSS packages that Google secures and uses
 into their own developer workflows. \nLearn more about <a href=\"https://cloud.google.com/security/products/assured-open-source-software\">Assured Open Source
 Software</a>, enable Assured OSS
 through our <a href=\"https://developers.google.com/assured-oss?utm_source=blog&amp;utm_medium=referral#get-started\"
 rel=\"noopener\" target=\"_blank\">self-serve onboarding</a>
 form, use the metadata API to list
 available Python and Java packages and determine which Assured OSS packages you
 want to use.</div>"
carlessian_info:
 news_filer_version: 2
 newspaper: Google Cloud Blog
 macro_region: Technology
url: https://cloud.google.com/blog/products/identity-security/how-to-choose-a-known-trusted-supplier-for-open-source-software/
rss_fields:
- title
- url
- summary
- author
- categories
- published
- entry_id
author: Jonathan Meadows

Language

Active

Ricc internal notes

Ricc source

Show this article Back to articles