{
"id": string,
"modified": string,
"published": string,
"withdrawn": string,
"aliases": [ string ],
"related": [ string ],
"package": {
"ecosystem": string,
"name": string,
"purl": string,
},
"summary": string,
"details": string,
"affects": [ {
"ranges": [ {
"type": string,
"repo": string,
"introduced": string,
"fixed": string
} ],
"versions": [ string ]
"references": [ {
"url": string
"ecosystem_specific": { see spec },
"database_specific": { see spec },
}
curl -X POST -d \
'{"commit": "a46c08c533cfdf10260e74e2c03fa84a13b6c456"}' \
"https://api.osv.dev/v1/query"
'{"version": "2.4.1", "package": {"name": "jinja2", "ecosystem": "PyPI"}}' \
Threat
Known example
How SLSA could have helped
A
Submit bad code to the source repository
Linux hypocrite commits: Researcher attempted to intentionally introduce vulnerabilities into the Linux kernel via patches on the mailing list.
Two-person review caught most, but not all, of the vulnerabilities.
B
Compromise source control platform
PHP: Attacker compromised PHP’s self-hosted git server and injected two malicious commits.
A better-protected source code platform would have been a much harder target for the attackers.
C
Build with official process but from code not matching source control
Webmin: Attacker modified the build infrastructure to use source files not matching source control.
A SLSA-compliant build server would have produced provenance identifying the actual sources used, allowing consumers to detect such tampering.
D
Compromise build platform
SolarWinds: Attacker compromised the build platform and installed an implant that injected malicious behavior during each build.
Higher SLSA levels require stronger security controls for the build platform, making it more difficult to compromise and gain persistence.
E
Use bad dependency (i.e. A-H, recursively)
event-stream: Attacker added an innocuous dependency and then updated the dependency to add malicious behavior. The update did not match the code submitted to GitHub (i.e. attack F).
Applying SLSA recursively to all dependencies would have prevented this particular vector, because the provenance would have indicated that it either wasn’t built from a proper builder or that the source did not come from GitHub.
F
Upload an artifact that was not built by the CI/CD system
CodeCov: Attacker used leaked credentials to upload a malicious artifact to a GCS bucket, from which users download directly.
Provenance of the artifact in the GCS bucket would have shown that the artifact was not built in the expected manner from the expected source repo.
G
Compromise package repository
Attacks on Package Mirrors: Researcher ran mirrors for several popular package repositories, which could have been used to serve malicious packages.
Similar to above (F), provenance of the malicious artifacts would have shown that they were not built as expected or from the expected source repo.
H
Trick consumer into using bad package
Browserify typosquatting: Attacker uploaded a malicious package with a similar name as the original.
SLSA does not directly address this threat, but provenance linking back to source control can enable and enhance other solutions.
- name: Generate provenance
uses: slsa-framework/github-actions-demo@v0.1
with:
artifact_path: <path-to-artifact/directory>
Follow