SLSA commitment

In the past few years, attacks compromising software supply chains (MITRE ATT&CK T1195) have become more prominent, with cases such as NotPeya, Target data breach, Solarwinds, … The impact of the SolarWinds attack in 2020 in the United States led to Executive Order 14028, which strongly focuses on improving the security and integrity of software supply chains. Since then, various initiatives have been started, either by governments or organizations, such as SSDF (“Secure Software Development Framework”) by NIST or the SLSA framework (“Supply Chain Levels for Software Artifacts”) by OpenSSF (2021).

SBOM

One of the key requirements mentioned explicitly in Executive Order 14028 is to provide a public SBOM (Software Bill Of Materials) for each distributed software component. AdaCore has for a long time maintained this information in its own systems but not in an easily exportable format. Each of our products now comes with an attached SPDX (System Package Data Exchange) file, which lists all the components used to create that product. Not only does it list all component versions, and the licenses they are subject to, but also the CPE (Common Platform Enumeration) information which allows us to know the possible CVEs (Common Vulnerabilities and Exposures) a component is affected by.

An important aspect when generating SBOMs is to ensure their accuracy. For years now, AdaCore has used ephemeral build servers with limited connectivity (basically our package manager and our repositories). While implementing SLSA Build Level 3, significant work has been done in order to reach the next level, which is a complete separation of the build control plane from the environment in which build recipes are run. In the process, we have also achieved hermeticism. This means that a given build is done in a context with no network connectivity, in which it only has access to the resources provided by the control plane. The control plane produces the SBOM based on this list of resources. As a consequence, this gives us the warranty that the generated SBOM contains all the resources used for a given component build. The next step is now to prove that the SBOMs are never altered once generated. For that, AdaCore will re-use the signature envelopes (DSSE, or Dead Simple Signing Envelope) also used to sign SLSA provenance files.

Vulnerability lists

The SBOMs are the base elements that can be used for vulnerability retrieval. By querying the NVD (NIST Vulnerability Database), we can determine whether an AdaCore product may be impacted by a CVE and, if so, how to remedy this problem.

The VEX (Vulnerability Exploitability eXchange) specifications are used to handle that part. The NTIA (National Telecommunications and Information Administration) initiated those specifications, which are issued by the CISA (Cybersecurity & Infrastructure Security Agency) to indicate the status of a product/component regarding a vulnerability.

This VEX specification is the last element needed to generate a vulnerability report. Starting with version 24.2, all AdaCore products also have a vulnerability report (along with the SBOM).

For each new CVE that may affect our products, a VEX file is created, and new issues are automatically assigned to the appropriate Product Engineering teams. Each team has to assess whether their product/component is affected by the vulnerability. Once all the teams have assessed the impact, the VEX file is updated, and a vulnerability report is generated and attached to the impacted components.

For our latest 24.2 release, 50 CVEs had to be investigated for all our products. As several products can be impacted by the same CVE, we performed about 180 assessments. Of those 50 CVEs

• 17 impact all the possibly affected products (mainly through the GTK stack of our IDE)

• 2 impact one of the possibly affected products, but not the others

• 8 have been fixed (through a patch)

• 23 do not impact any product (mainly because the vulnerable code is not used in our products)