Software supply chain attacks are on the rise and the need to respond to this attack vector has become crucial. But where do you begin?
If you had the attacker’s battle plans, you could prioritize your efforts accordingly. We do not have a specific attacker’s plans, but we do have a blueprint of typical attacker battle plans—the CI\CD threat matrix based on the MITRE att&ck framework.
Reading the table below from left to right leads us through the attack cycle: the attacker needs to gain initial access, then execute the code, reach persistence, build up capabilities by privilege escalation, defense evasion, and credential access. In this manner, attackers can perform a lateral movement in order to reach their prey, and then attack—either exfiltrate or cause other impacts.
Each column of the table lists techniques the attacker may use. For example, the first column suggests that initial access could be gained by either a prior compromise of the CI\CD, or by weak access controls (valid account of a Git service, valid account of a CI\CD service, or valid admin account of a critical server).
Scribe’s evidence-driven approach to securing the supply chain is essentially simple:
Trust an artifact only if it is associated with supporting evidence, signed evidence which are defined as digital attestations.
To implement this approach, Scribe supplies the software tools needed to collect and manage such evidence and evaluate the trustworthiness of the artifact according to policies and attestations (signed evidence).Get Solution Brief
Examples of policies supported by Scribe:
Security settings policies
Ensure that the security settings of the services used during the build process meet a predefined standard.
Source\File\Module modification policies
Verify that source code, configurations, build scripts, and IoC files have been modified according to a predefined standard that defines the identities, processes, steps, and states.
Source\File\Module integrity policies
Assure that source code, files, and modules are identical to predetermined allowed versions.
Dependency trust policies
Assure that the dependencies used are up to a predefined standard (such as OSSF Scorecard, version-age, allow\ban list).
Ensure that dependencies and other public-source (closed or open) components do not pose a high security risk.
Software Development Lifecycle policies
Make sure that code has been reviewed by stakeholders, comments have been resolved, and testing and security testing has been completed successfully.
Pipeline behavior policies
Maintain pipeline behavior according to plan. For example, require that an image is pushed as the output of the pipeline and not by some other process.
Examples of evidence Scribe collects continuously and automated for every build:
Fine grained SBOMs from the source SCM as well as final artifacts (containers)
Snapshots of the build environment
Snapshots of the source-repo
Security setting of the source-control and build environment
OS-level relevant events collected from the build machine