-
-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add formulation support #31
Comments
It could be hard to come up with a way to identify, in a machine readable way, all the different potential tools. I'm wondering if maybe the first step should be things like ISO infosec standards/certifications, OWASP SAMM/ASVS/SCSC levels and things like that? |
And in that vein, maybe there should be a an indicator if it is a component or organisation level thing? And whether it is just a basic assertion, we've done a self assessment or we've had an independent assessment done. And who did it and a reference to the self assessment/certification? I think it would be much easier to incorporate that type of information into a workflow than specifying all the individual tools. Not that the above doesn't have value. I'm just thinking about how easy it would be to incorporate it into component assessment workflows. And I think I would get much more value from higher level information. |
We are creating a tool that will generate verifiable environment attestation data. I would like to have a way to reference or embed these attestations in CycloneDX
|
@colek42 In the example provided:
|
They are signed DSSE envelopes available in a log or as files. We use Rekor in our initial architecture. here is an example of a entry: https://log.testifysec.io/api/v1/log/entries?logIndex=125 |
Per https://twitter.com/ariadneconill/status/1506291663232241679 there's also a need to include build log support in formulation. |
It would be very interesting to see "formulation" get into CDX v1.5 release! My project is trying to figure out a way to generate SBOM which can be used by our users to build locally and create exactly the same binaries as the "reproducible build". |
@zdtsw I had an intro conversation with Pete Allor a few weeks ago. I'd be really interested in hearing from you (and others) at RedHat about some of the requirements you have wrt formulation. |
Here is the section of the SARIF spec that focuses on tool description. We are still wrestling with this... particularly how to capture configuration and runtime environment. Obviously can get quite complex. https://docs.oasis-open.org/sarif/sarif/v2.1.0/csprd01/sarif-v2.1.0-csprd01.html#_Toc10540971 |
@stevespringett Here is the Event-Trigger-Task presentation I promised... |
@stevespringett @msymons |
Every component and/or pedigree should support how the component was made, not only what the component is or its dna.
For high assurance use cases, it is important to document how software is created, tested, verified, etc.
A possible method may be to support parallel and sequential pipeline and steps within a pipeline. Each step could potentially represent:
The text was updated successfully, but these errors were encountered: