The supply chain is the process by which projects are developed, distributed, operated and maintained.
With the growing use of software components, multiple source contributions, accelerated code release rates and more, modern software development has become faster and more complex. Recent cyberattacks on the integrity of the software production chain (Log4shell, SolarWinds, LastPass) have led to a global awareness of the associated risks.
Depending on the environment, it is often easier for an attacker to target a sub-element of the project (a supplier with lesser security, for example).
The consequences can be disastrous from a monetary point of view, but also from a legislative point of view (cf; RGPD and Cyber Resilience Act). The cyber risks to the supply chain are manifold, from design to maintenance. Cyber attacks can lead to data inaccessibility, corruption or theft.
Awareness and the adoption of effective cybersecurity strategies are therefore the only levers for tackling this threat and ensuring that all links in the supply chain are satisfactorily secured.
We took part in the Software Supply Chain Security event organized by Systematic on Thursday June 1, 2023(link to the event).
Here's what we took away from the day:
- Definition of SBOM
- How SNCF manages its Docker image pool with labels
- Introducing the SLSA framework
- Introducing ScoreCards
- Step Security tool presentation
- Introducing the OtterDog tool
- Presentation of Trivy and Grype tools
- The importance of a reproducible build system
- Presentation of the software archive project
- Risk explorer project presentation
Software Bills of Material or SBOM is a list of dependencies used for a project.
The SBOM is commonly used to monitor the vulnerabilities that would be published for the dependencies used. Note that it can also be used as a reference list when you want to build an older version of a project.
The SNCF presented a REX on its Docker infrastructure and the practices implemented:
- The limitation to a few basic Docker images.
- Labeling (adding metadata) of images (e.g. adding a unique ID, listing the tools the image contains, etc.).
- Implementation of Docker monitoring tools (such as Datadog).
During the Log4J / Log4Shell episode, these practices made it possible to identify which Docker containers were affected by the vulnerability, and to monitor the remediation process.
Introducing the SLSA framework
The current version of the Supply-chain Levels for Software Artifacts (SLSA) framework (available here: https://slsa.dev/) describes the different security levels of a built artifact (0 to 4, 0 being the basic level without doing anything in particular, and 4 being the most robust level).
The tool checks whether the repo applies certain best practices and gives it a score from 0 (bad) to 10 (very good).
Step Security tool presentation
The Step Security tool(https://www.stepsecurity.io/) consists of 2 products:
- A robot that applies the suggestions offered here https://app.stepsecurity.io/securerepo for a Github repo.
- It can update Dependabot's configuration.
- Suggestpinning certain versions of dependencies (e.g. in Docker using the SHA256 of a base image).
For example, here is a Pull-requests where it proposes to restrict the permissions of a Github workflow: https://github.com/apache/cloudstack/pull/6802.
- A Github Action https://github.com/step-security/harden-runner to reinforce the security of a github workflow.
Introducing the OtterDog tool
OtterDog (available here: https://gitlab.eclipse.org/eclipsefdn/security/otterdog) lets you configure your organization and Github repo via code in the same way as other IaC-type tools.
Presentation of Trivy and Grype tools
- Docker images.
- A file directory.
Have a build pipeline that can build the same output for the same input.
This requires enumerating the dependencies used for generation (third-party lib, compilation tool, ...) (some tools make network requests, some set up a proxy to replay the response to these requests).
The main advantage is that an external person is able to verify the integrity of the supplied application (its built version is identical to ours). If you need to backport an older version, you can always build your own.
Presentation of the software archive project
The project, which can be accessed here https://archive.softwareheritage.org, aims to provide a stable archive of all publicly written code.
As an example, here is the Parsec code: https: //archive.softwareheritage.org/browse/origin/directory/?origin_url=https://github.com/Scille/parsec-cloud.
Perhaps useful to provide an additional source in the SBOM.
Risk explorer project presentation
This project provides an interface for exploring the various cybersecurity risks that exist, as well as a list of publications related to a given risk.
It was a very rewarding day, as we were able to discover new tools and practices and get feedback on their use.
We will be implementing some of these tools and best practices at Parsec. This will be the subject of future articles!
Checksum, also called hash or checksum, generated from a block of data to verify its integrity.
Dependabot is a tool (a robot) that will propose pull-requests to update the dependencies used in a Github project.
A Github action is a block of code that can be reused in a Github workflow.
Infrastructure as Code
Article written by :