GCP – How to choose a known, trusted supplier for open source software

The diagram above highlights key open source attack vectors.  We can divide the common software supply chain security attacks into five main types:

Attacks at runtime leveraging vulnerabilities in the code  
Attacks on the repositories, tooling and processes 
Attacks on the integrity of the artifacts as they progress through the pipeline
Attacks on the primary open source dependencies that customers applications leverage
Attacks throughout the inherited transitive dependency chain of the open source packages 

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 95% of the vulnerabilities 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. 

Recent guidance from CISA 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:

Have an up-to-date inventory of their own external dependencies.  
Demonstrate knowledge and control of all ingest points.  
Leverage a single production build service so that they can maintain a singular logical control point. 
Meet best practice standards for managing their infrastructure including:

Well designed separation of duties and IAM control

Built-in organizational policy and guard rails to secure Zero Trust network design

Automated and regular patching with associated evidence

Support for these posture controls with complementary continuous threat detection with detection, logging and monitoring systems.

Bonus points if they operate with “everything as code” and with hermetic, reproducible and verifiable builts.      

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. 

Trust but verify

It is also important that the trusted supplier provide supporting evidence and insights. This evidence includes:

Checkable attestations on infrastructure security and processes via third party certifications and/or your own independent audit.  
Checkable attestations for the security posture and processes for their SDLC against a standard framework like SLSA or SSDF.   
Cryptographic signatures on the served packages and any associated accompanying metadata so that you can verify source and distribution integrity.

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.

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:  

Standard SBOM with SCA insights – vulnerabilities, licensing info, fully mapped transitive dependencies and associated vulnerability and licensing risk.  

VEX statements for how the inherited vulnerabilities from transitive dependencies affect the primary package being served. 

Any related threat intelligence specific to the package, use case, or your organization.

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.

Better control and balancing benefits of open source components

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 Assured Open Source Software (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 Assured Open Source Software, enable Assured OSS through our self-serve onboarding form, use the metadata API to list available Python and Java packages and determine which Assured OSS packages you want to use.