Add dependency track - #1627
Conversation
✅ Deploy Preview for slsa ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
I took some of S2C2F requirements that made sense and were attestable along with some other thoughts. Normally I would keep the gem update separate but we were on an EOL version. I used Claude to help structure, do some sanity checking, and to bounce ideas off of.
|
|
||
| ## Examples | ||
|
|
||
| ### Minimal L1 |
There was a problem hiding this comment.
Could you include an example of an L1 attestation for Git / VCS ingestion?
That's probably the next most common dependency import path after package managers. Maybe I'm overthinking it IRT to the spec itself, but this proposed schema seems like it could be a bit awkward to use with version control systems because there would either be a lot of duplication of values across fields, or some immediate corner cases.
For example, the subject digest:
Would this just be the commit sha? Would this commit SHA then expect to be repeated in other places like version, or would version in that case be an appropriate tag, even though this is not immutable and could be multiple? If you downloaded a tarball of a git repo the SHA would be the digest of the tarball, but this wouldn't apply to any other git use case. I suppose this could be a dependency platform design choice but it could make the spec confusing for consumers.
There was a problem hiding this comment.
This is a good point worth discussion in an upcoming SLSA meeting. If you're available I think your thoughts would be valuable.
They happen at 12PM Eastern time on Mondays. See: https://openssf.org/calendar/ for details on the Zoom link and stuff.
The thing we generally recommend with the build track is just using the git commit hash in cases like this. As long as it's clear what the hash refers to via the subject via like a url it should be good. But maybe we should be a bit more specific.
There was a problem hiding this comment.
We had a good discussion around this during our call today - there is a clear need to address when dependencies are included in source (whether it be through vendor-ed code or git submodules). We need to brainstorm on how we can be able to enable these dependency track evaluations on source based dependencies as well (distinguishing between the decision to use a new library or a new version, to evaluating the provenance and properties of the actual bytes ingested).
The source track needs to either surface that information or include evaluation of those dependencies within its evaluation of its level. I.e. Perhaps a source attestation should have a source Level for provenance, but also expose a dependency level certification for all its dependencies.
There was a problem hiding this comment.
Great to hear!
Unfortunately I'm in APAC (Australia), so the US east timezone is very challenging for me to work with, but please let me know if there's a better format to discuss or give feedback or thoughts in other than a PR. I'd love to be involved.
The other potential ingest types I can see needing to be supported to make this robust for large project use cases would be archive packages from misc download locations i.e not git or package manager releases and potentially binaries for a similar type of case.
There was a problem hiding this comment.
I've thought a bit more about this and for this comment, i'm naming a concept "Dependency Fog" - the impeding factors that make it so that dependencies are no clearly articulated and indexable so that they can be evaluated..
Dependency fog not only shows up by the issues with source (binary inclusions, vendored source, etc.) but also within the build space (i.e. having a non-hermetic build can pull in dependencies that we cant validate).
One approach here would be to provide some indication of evaluation of dependency fog.. This is a hard problem, but I think there can be multiple levels here (from scans providing some heuristics of known fog, vs certainty from using a declarative build system - e.g. bazel).
Concrete suggestions - please let me know the best way to contribute here.
- We can effectively reduce the introduced source dependencies into the binary/artifact dependency problem: The problem today in build attestation as source is treated opaque. Perhaps have a dependency attestation for a source repo that will provide any indications of dependency fog and provide a way to surface those dependencies if they exists (list of binaries, submodules, etc.) that need to be considered in evaluation. - every source input to a build will need this attestation to be evaluated.
- From a policy perspective, I think we need to provide a way to reason about source and builds (materials complete) as well so that we can certify those sources for some properties of dependency fog.
- We probably can add in a list of cases that we've considered.
| Case | Ingestion event | Dependency indexable? | Digest |
|---|---|---|---|
Vendored source tree (go mod vendor, cargo vendor, manual copy) |
the vendoring commit | yes, at vendoring time | dirHash/gitTree over the subtree |
| Submodule pin/bump | the gitlink update | yes — URL + commit are in the tree | gitCommit |
Checked-in 3p binary (vendor .so, prebuilt toolchain) |
the commit adding it | usually, from the vendor's release page | blob digest |
| Checked-in minified JS bundle | the commit adding it | often, from the CDN/registry version | blob digest |
|
|
||
| ## Purpose | ||
|
|
||
| Describe how a single third-party dependency entered an ingestor's |
There was a problem hiding this comment.
Is a "single third-party dependency" considered to be result of fetching a dependency from a prescribed source? I think the "single dependency" language is a bit unclear when it comes to anything outside package managers (though my concern may also apply there). Git is somewhat of the wild west, but also a very typical dependency import path for large projects.
Some repos are notorious for packaging pinned third party sub-dependencies in the parent repo via either vendoring or git submodule eg. https://github.com/google/ruy. These are often invisible to scanners and SBOM generation pipelines since they were implicitly imported. Anything that could make these more visible would be fantastic.
For clarity, is the single third party dependency that's expected to have the attestation just the top level one?
There was a problem hiding this comment.
This is a good point. I will bring it up in the next SLSA meeting.
We've mostly been considering things downloaded via package managers or just binaries downloaded through something like http.
There's always going to be a challenge with something like vendoring.
| "ingestor": { "id": "https://example.com/" }, | ||
| "ingestionPlatform": { "id": "https://artifactory.example.com/" }, | ||
| "upstream": { | ||
| "registry": "https://registry.npmjs.org/", |
There was a problem hiding this comment.
In the git case, a repo path is not necessarily sufficent to uniquely identify a repository. Might be worth adding an optional repo_id or other unique identifier for those who care about this. Low volume org/repo names can be recycled on places like GitHub, which could lead to future confusion about the source of code.
There was a problem hiding this comment.
Yes, this another good point.
|
|
||
| ## Examples | ||
|
|
||
| ### Minimal L1 |
There was a problem hiding this comment.
I've thought a bit more about this and for this comment, i'm naming a concept "Dependency Fog" - the impeding factors that make it so that dependencies are no clearly articulated and indexable so that they can be evaluated..
Dependency fog not only shows up by the issues with source (binary inclusions, vendored source, etc.) but also within the build space (i.e. having a non-hermetic build can pull in dependencies that we cant validate).
One approach here would be to provide some indication of evaluation of dependency fog.. This is a hard problem, but I think there can be multiple levels here (from scans providing some heuristics of known fog, vs certainty from using a declarative build system - e.g. bazel).
Concrete suggestions - please let me know the best way to contribute here.
- We can effectively reduce the introduced source dependencies into the binary/artifact dependency problem: The problem today in build attestation as source is treated opaque. Perhaps have a dependency attestation for a source repo that will provide any indications of dependency fog and provide a way to surface those dependencies if they exists (list of binaries, submodules, etc.) that need to be considered in evaluation. - every source input to a build will need this attestation to be evaluated.
- From a policy perspective, I think we need to provide a way to reason about source and builds (materials complete) as well so that we can certify those sources for some properties of dependency fog.
- We probably can add in a list of cases that we've considered.
| Case | Ingestion event | Dependency indexable? | Digest |
|---|---|---|---|
Vendored source tree (go mod vendor, cargo vendor, manual copy) |
the vendoring commit | yes, at vendoring time | dirHash/gitTree over the subtree |
| Submodule pin/bump | the gitlink update | yes — URL + commit are in the tree | gitCommit |
Checked-in 3p binary (vendor .so, prebuilt toolchain) |
the commit adding it | usually, from the vendor's release page | blob digest |
| Checked-in minified JS bundle | the commit adding it | often, from the CDN/registry version | blob digest |
| for cases where upstream guarantees are absent. The track defines a | ||
| per-ingestion attestation, Dependency Ingestion Provenance, and grades | ||
| the platform's claims about each ingested dependency across three levels: | ||
| L1 Inventoried (identity and content), L2 Controlled (controlled ingest |
There was a problem hiding this comment.
I agree on identity and content here, i think inventoried may be confused with knowing all dependencies. I suggest that we rename this - maybe Integrity or Provenance?
There was a problem hiding this comment.
- 1 for something related to provenance
Updates the **Active workstreams** table to reflect the current state agreed in the SLSA community meeting. Changes: - **Build Level 4** — shepherd handed off from David A. Wheeler to [Andrew McNamara](https://github.com/arewm) (`@arewm`) - **Attested Build Environments Track** — ongoing, unchanged - **Source Track** — completed, removed - **Version 1.2 release** — completed, removed - **Dependency Ingestion Track** (new) — shepherded by [Mike Lieberman](https://github.com/mlieberman85) (`@mlieberman85`), linked to #1627 - **SLSA Tooling Modernization** (new) — shepherded by [Adolfo García Veytia](https://github.com/puerco) (`@puerco`), linked to [ossf/tac#537](ossf/tac#537) A 1.3 release-cut workstream is expected in the future and can be added when it kicks off. --------- Signed-off-by: Brandon Lum <lumjjb@gmail.com>
4 participants
I took some of S2C2F requirements that made sense and were attestable along with some other thoughts.
Normally I would keep the gem update separate but we were on an EOL version.
I used Claude to help structure, do some sanity checking, and to bounce ideas off of.