Securing pipelines using Scribe

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).

Source: Common Threat Matrix for CI/CD Pipeline

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).

Vulnerabilities policies

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.