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.
Topics covered
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
Definition of SBOM
Software Bills of Material or SBOM is a list of dependencies used for a project.
Generally speaking, this list contains the name, version and checksum[1] of a dependency, and takes the form of a file. There are currently two standards for the file format: CycloneDX and SPDX.
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.
How SNCF manages its Docker image pool with labels
The SNCF presented a REX[2] 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).
Introducing ScoreCards
ScoreCards(https://securityscorecards.dev/) is a tool maintained by OpenSSF that enables simple auditing of a Github repo.
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[3].
- 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[4] 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[5].
Presentation of Trivy and Grype tools
The Trivy and Grype tools are used to search for vulnerabilities in:
- Docker images.
- A file directory.
Trivy specializes in infrastructure analysis (Docker, AWS, Kubernetes). Grype, on the other hand, focuses more on language-specific analysis (Rust, Java, Python, Javascript), using the Syft tool.
The importance of a reproducible build system
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.
https://reproducible-builds.org/
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.
https://sap.github.io/risk-explorer-for-software-supply-chains/
Conclusion
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!
[1]Checksum, also called hash or checksum, generated from a block of data to verify its integrity.
[2]Feedback
[3]Dependabot is a tool (a robot) that will propose pull-requests to update the dependencies used in a Github project.
[4]A Github action is a block of code that can be reused in a Github workflow.
[5]Infrastructure as Code
Article written by :
Florian Bennetot
Marcos Medrano
2023-06-08
