AdaCore Software Supply Chain Security Evolution

In this blog:

• Why governments in the US and EU are tightening cybersecurity and software supply-chain requirements
• How AdaCore aligns with key frameworks such as CMMC, NIST SSDF and SLSA to strengthen trust and compliance
• What achieving SLSA Build Level 3 means for the security and integrity of AdaCore’s build system
• How signed SBOMs and provenance files improve transparency and audit readiness for customers
• The role of hardened, isolated builds in protecting build artefacts and metadata
• How these initiatives support long-term software assurance and evolving regulatory expectations

Context

In recent years, amid the growing number of cyberattacks, various state initiatives have emerged to prevent or mitigate their impact.

In the United States, any direct or indirect subcontractor to the DoD must implement certain security frameworks. For example, the protection of Federal Contract Information (FCI) and Controlled Unclassified Information (CUI) is governed by the CMMC 2.0 framework. AdaCore has CMMC Level 2 conformance across the entire company, regardless of whether CUI or FCI is involved. Controls from NIST 800-171 have been implemented.

In the EU, legislation such as the Digital Operational Resilience Act (DORA), the Cyber Resilience Act (CRA), and the Network and Information Security directive (NIS2) aim to improve the general public’s and economic actors’ confidence in the IT offering within the European Community. The European Union Agency for Cybersecurity (ENISA) has also produced an EU-centric version of the well-known Common Criteria (EUCC).

Regarding the Software Supply Chain, the primary US initiative is the Secure Software Development Framework (SSDF) (NIST 800-218), which was a key outcome of Executive Order 14028. Recent executive orders have lowered the requirements regarding artifact attestation. Still, AdaCore has decided to continue the internal initiative and take it more as an opportunity to increase our confidence level rather than a pure constraint and conformance issue. This also establishes trust between AdaCore and its customers.

We adopted SLSA (Supply Chain Levels for Software Artifacts) for implementing attestations, primarily influenced by resources such as the blog post, "SLSA for Success: Using SLSA to help achieve NIST’s SSDF," when we began this effort. Our expectation is that leveraging SLSA will enable us to meet both current and future software supply chain requirements.

What’s New

After adding SBOM and Vulnerability Lists to our build artifacts (“Secure Supply Chain and vulnerability reports at AdaCore”) for release 25, the following key features have been added to our supply chain for release 26:

• Generation of SLSA build provenance files (SLSA build level 1)
• Signing of the metadata associated with the build artifacts. This includes signing of SLSA build provenance metadata (SLSA build level 2) and our SBOM metadata
• Better build hardening through the formalization of a completely isolated control plane (SLSA build level 3)

The main outcome is that the AdaCore build system is now compliant with SLSA build level 3. This achievement, combined with conformance with CMMC Level 2 and updates to our engineering procedures at both the organizational and project levels, enables us to implement SSDF's recommendations and thus meet the objectives of the original Executive Order 14028.

Provenance Files

Starting with the AdaCore 26.1 release, provenance files will be delivered along with the components available to customers. While the already available SBOMs provide information about the sources used to build a given component, the new provenance files will provide additional information on how the component was built.

Provenance files provided by AdaCore are in-toto attestations using the specification from SLSA https://slsa.dev/provenance/v1. The provided data is as follows:

1. Build internal parameters: some internal parameters of the AdaCore build system. Some of these parameters may have an interpretable meaning outside the AdaCore system (build date, build platform, version, …). Some others are internal identifiers that are meaningful only for AdaCore teams. Presenting them to an external audience is not a security concern. In the event of an audit by an external entity, AdaCore can use them to provide evidence from our internal logs and dashboards.
2. Resolved Dependencies: a set of resources that were used during the build of a given component. Various kinds of resources are present:
   1. The sources used to build the component (also present in the SBOM).
   2. The subcomponents are integrated into the component (also present in the SBOM). Note that each subcomponent also has its own attestation.
   3. The source and components needed to build the component. Some of these resources may be publicly available directly or indirectly (for example, sources of tools such as GNU Make). Some other resources are private components or sources used by AdaCore to drive the build. Again, this information may be useful in demonstrating that we have full traceability of our environment in the event of an audit or incident.
3. Builder Dependencies: pointers to some internal resources, such as the AWS instance on which the build ran, the AMI used, the version of the infrastructure software used, etc. This information can be used in the event of an incident to link a specific build with lower-level logs, such as AWS CloudTrail logs.
4. Byproducts: internal links to other resources produced during the build process.

In addition to the benefits related to Software Protection (PS) and Incident/Vulnerability Response (RV), providing this data to our customers enhances transparency regarding how AdaCore produces software.

Metadata Signing

Trust in the metadata (including both SBOM and provenance files) is a key aspect, and AdaCore needs to ensure that it cannot be tampered with or that a malicious actor cannot forge random attestations. Tampering with the metadata would make the detection or containment of an attack impossible. To address this and, as a consequence, to be SLSA Level 2 compliant, AdaCore put a signature system in place for the produced metadata using the DSSE format recommended by SLSA.

After studying existing solutions such as Rekor, we decided to take a more “cloud-native” approach and take as much advantage as possible of the AWS Shared Responsibility model regarding security. Similarly to the Sigstore approach, we are using short-lived X.509 certificates. The PKI is managed by the AWS Private CA service. Logging of signing operations, certificates, and the associated metadata is then stored safely using AWS S3 Object Lock, which ensures that the data cannot be altered or deleted (see the SEC and CFTC compliance report). For the external user, two important pieces of information can be retrieved from that protected bucket: the X.509 certificate associated with the private key used to create the signature and the time at which the signing was performed. The end-user can then verify that the signature is correct, associate it with an identity (typically the AdaCore build service), and finally confirm that the signature was performed within the validity period of the certificate.

Hardened Build

Tampering with the metadata during their generation is another (and harder to achieve) level of attack on a build system. To protect us against those issues and then achieve SLSA Build Level 3, the framework recommends using hardened builds (isolated builds). The goal is to prevent the following attacks:

• Prevent tampering/forging of metadata (provenance, SBOM)
• Prevent secret material used to sign the metadata from being accessible to the user-defined build steps
• Prevent runs from influencing one another, even within the same project

Achieving SLSA Build Level 3 compliance has been addressed at AdaCore by running ephemeral build instances, which execute each part of the build in distinct hermetic environments.

The ephemeral build instances are Amazon AWS-hosted virtual machines. They implement the core of the Secure Control Plane as defined in the SLSA framework. Each server is responsible for producing a set of components by running build recipes, generating the associated metadata, and signing them. The servers have the following properties:

• They are ephemeral and cannot be reused in another context
• Connection is limited to core AdaCore services, such as our artifact repository or the signing service
• No one can connect to them (no SSH server, …)

When running a given build recipe, the server executes it within a dedicated hermetic environment implemented as a container with no network connectivity and restricted access to the host file system. This ensures that a build recipe does not have access to sensitive services such as the signing service and that the build recipe has only access to the resources declared statically in the recipe. This is how we can ensure precise and safe metadata generation and signing. Since 25.2, all our builds on both Linux and Windows hosts are running in this mode.

Conclusion

The AdaCore build system is now compliant with SLSA build level 3. This achievement, combined with conformance with CMMC Level 2 and updates to our engineering procedures at both the organizational and project levels, enables us to implement SSDF's recommendations and thus meet the objectives of the original Executive Order 14028. AdaCore customers will receive provenance files through the AdaCore product delivery channels that they can use to strengthen their own software supply chain practices.

Glossary