Closed stevespringett closed 1 year ago
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
{
"_type": "https://in-toto.io/Statement/v0.1",
"subject": [
{
"name": "git:dbce6af7499804957f9c8b799455488a8ed5a01e",
"digest": { "sha1": "dbce6af7499804957f9c8b799455488a8ed5a01e" }
},
{
"name": "helloworld",
"digest": {
"sha256": "13fed16845d228d4adfc3bdf69058ebbacc682555ac1d88188939f44acb77aa2"
}
},
{
"name": "https://gitlab.com/testifysec/demos/witness-demo/-/pipelines/411938289",
"digest": {
"sha256": "e50bc94c714a1be822c1588c96de96d29687883d15c9a747265825c863804827"
}
},
{
"name": "https://gitlab.com/testifysec/demos/witness-demo/-/jobs/1797992628",
"digest": {
"sha256": "441d7eb2133d3344af3e66758ec9c6940991e5913de2e4d8b83af264e0dac171"
}
}
],
"predicateType": "https://witness.testifysec.com/AttestationCollection/v0.1",
"predicate": {
"name": "build",
"attestations": [
{
"type": "https://witness.testifysec.com/attestations/Gitlab/v0.1",
"attestation": {
"jwt": {
"token": "",
"claims": {
"exp": 1637263067,
"iat": 1637259467,
"iss": "gitlab.com",
"job_id": "1797992628",
"jti": "8ed26f15-73df-43c6-8d96-df0c96aa4d93",
"namespace_id": "13468192",
"namespace_path": "testifysec/demos",
"nbf": 1637259462,
"pipeline_id": "411938289",
"pipeline_source": "push",
"project_id": "31413154",
"project_path": "testifysec/demos/witness-demo",
"ref": "new_attestations",
"ref_protected": "false",
"ref_type": "branch",
"sub": "job_1797992628",
"user_email": "mswift@mswift.dev",
"user_id": "3782831",
"user_login": "mikhailswift"
}
},
"ciconfigpath": ".gitlab-ci.yml",
"jobid": "1797992628",
"jobimage": "registry.gitlab.com/testifysec/demos/witness-demo/builder:5",
"jobname": "build",
"jobstage": "build",
"joburl": "https://gitlab.com/testifysec/demos/witness-demo/-/jobs/1797992628",
"pipelineid": "411938289",
"pipelineurl": "https://gitlab.com/testifysec/demos/witness-demo/-/pipelines/411938289",
"projectid": "31413154",
"projecturl": "https://gitlab.com/testifysec/demos/witness-demo",
"runnerid": "12270840",
"cihost": "gitlab.com"
}
},
{
"type": "https://witness.testifysec.com/attestations/Artifact/v0.1",
"attestation": {
".dockerignore": {
"sha256": "87d7e75ecd018aeef5f63a2aa0743f82506a37727524d4ad1f778ccca33c9cc2"
},
".git/HEAD": {
"sha256": "28d25bf82af4c0e2b72f50959b2beb859e3e60b9630a5e8c603dad4ddb2b6e80"
},
".git/ORIG_HEAD": {
"sha256": "eb72712a87dfde8787d2676c127968dd5954714b8b84e5f60beb2a546bb81262"
},
".git/config": {
"sha256": "a5954da8f6c442b5494a6b2f7f4b18b2f058aa168c01c680efc3444e92e57aeb"
},
".git/description": {
"sha256": "85ab6c163d43a17ea9cf7788308bca1466f1b0a8d1cc92e26e9bf63da4062aee"
},
".git/hooks/applypatch-msg.sample": {
"sha256": "0223497a0b8b033aa58a3a521b8629869386cf7ab0e2f101963d328aa62193f7"
},
".git/hooks/commit-msg.sample": {
"sha256": "1f74d5e9292979b573ebd59741d46cb93ff391acdd083d340b94370753d92437"
},
".git/hooks/post-update.sample": {
"sha256": "81765af2daef323061dcbc5e61fc16481cb74b3bac9ad8a174b186523586f6c5"
},
".git/hooks/pre-applypatch.sample": {
"sha256": "e15c5b469ea3e0a695bea6f2c82bcf8e62821074939ddd85b77e0007ff165475"
},
".git/hooks/pre-commit.sample": {
"sha256": "f9af7d95eb1231ecf2eba9770fedfa8d4797a12b02d7240e98d568201251244a"
},
".git/hooks/pre-merge-commit.sample": {
"sha256": "d3825a70337940ebbd0a5c072984e13245920cdf8898bd225c8d27a6dfc9cb53"
},
".git/hooks/pre-push.sample": {
"sha256": "ecce9c7e04d3f5dd9d8ada81753dd1d549a9634b26770042b58dda00217d086a"
},
".git/hooks/pre-rebase.sample": {
"sha256": "4febce867790052338076f4e66cc47efb14879d18097d1d61c8261859eaaa7b3"
},
".git/hooks/pre-receive.sample": {
"sha256": "a4c3d2b9c7bb3fd8d1441c31bd4ee71a595d66b44fcf49ddb310252320169989"
},
".git/hooks/prepare-commit-msg.sample": {
"sha256": "e9ddcaa4189fddd25ed97fc8c789eca7b6ca16390b2392ae3276f0c8e1aa4619"
},
".git/hooks/push-to-checkout.sample": {
"sha256": "a53d0741798b287c6dd7afa64aee473f305e65d3f49463bb9d7408ec3b12bf5f"
},
".git/hooks/update.sample": {
"sha256": "8d5f2fa83e103cf08b57eaa67521df9194f45cbdbcb37da52ad586097a14d106"
},
".git/index": {
"sha256": "892aa8a392c6b3d9b61a28365cd340e991b421f962096b0011ee7f0241074def"
},
".git/info/exclude": {
"sha256": "6671fe83b7a07c8932ee89164d1f2793b2318058eb8b98dc5c06ee0a5a3b0ec1"
},
".git/logs/HEAD": {
"sha256": "ff9e65be71b62a41141251d1449fa70f0d1f27a07ed57c6a688293625a523837"
},
".git/logs/refs/heads/main": {
"sha256": "ff9e65be71b62a41141251d1449fa70f0d1f27a07ed57c6a688293625a523837"
},
".git/logs/refs/remotes/origin/HEAD": {
"sha256": "4ada9f7f7211411c3411ed03c004a970ebc055dc83abbd2627a7b8087ddfd783"
},
".git/objects/pack/pack-e0de4aaa9b056bc373b774f2883bc71389ef5c6f.idx": {
"sha256": "fad7cbdcc8d3c70641121021f09dc97d9393bfa131803758709a9d93174c418c"
},
".git/objects/pack/pack-e0de4aaa9b056bc373b774f2883bc71389ef5c6f.pack": {
"sha256": "3f4b99a63deebf6f93a38553dd9448a3e973d768d56f150b209c48e364e44a6b"
},
".git/packed-refs": {
"sha256": "ae268e78e389cedddd2e047057f643807952c7329685ea5dbd42a6c65084d0df"
},
".git/refs/heads/main": {
"sha256": "bf7549e832d6f13b1d05613b3b93a1ead01b8a1fec5e911535361c2b4794cdc5"
},
".git/refs/remotes/origin/HEAD": {
"sha256": "2bb6a24aa0fc6c484100f5d51a29bbad841cd2c755f5d93faa204e5dbb4eb2b4"
},
".gitlab-ci.yml": {
"sha256": "a636f1638bfe583316eb70e32cf8143d6a010b197254e1e4a34042f29c15d083"
},
"Dockerfile": {
"sha256": "33b3300044f6e3d2d21cd7151c04c8e58d45f31bdd3fe59bdf7f440ffd4f5df0"
},
"Dockerfile.builder": {
"sha256": "4b5b6ef6db129b119d79699327484452362831bfc5aec2f20bd338adbb8bbc73"
},
"README.md": {
"sha256": "49caac9effe749374dc21cf11e6a5fb85bb6bafbbd798c5e59e6b62af4232d79"
},
"go.mod": {
"sha256": "d926536795932323ba88bcd499981ccd626f47600e5a9d30c8f00f91a6b45ab9"
},
"main.go": {
"sha256": "d9a686853bb091c4e6a6ccd0646553d2ebec3f4b99814fdd21e184096a6918bf"
},
"policy.json": {
"sha256": "99d7e3eba4f0515afac126487ba9e1f8f5896c0b71d6c9d9faa8f179c15a7a26"
},
"policykey.pub.pem": {
"sha256": "9f2a08707131d090c99ccb35a7ce2e6f2ded9acc02c09bb378e59a14397f29f1"
}
}
},
{
"type": "https://witness.testifysec.com/attestations/Git/v0.1",
"attestation": {
"commithash": "dbce6af7499804957f9c8b799455488a8ed5a01e"
}
},
{
"type": "https://witness.testifysec.com/attestations/CommandRun/v0.1",
"attestation": {
"cmd": ["go", "build", "-o", "helloworld", "./main.go"],
"exitcode": 0,
"products": {
"helloworld": {
"sha256": "13fed16845d228d4adfc3bdf69058ebbacc682555ac1d88188939f44acb77aa2"
}
}
}
}
]
}
}
@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". This requires us to detail basically everything from build environment: kernel level, packages installed on the build machine, gcc etc. From reading of https://owasp.org/www-community/Component_Analysis, it looks like such info can be grouped into formulation section in SBOM.
@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... 2022-10-24 Event-Trigger-Task.pdf 2022-10-24 Event-Trigger-Task.pptx
@stevespringett @msymons
Link to formulation schema proposal (PPTX, draft) from the 2/13/2023 WG meeting:
https://docs.google.com/presentation/d/1ND37Oqvmx4uy_nU1QeevbLsk_hy9aVCa/edit?usp=share_link&ouid=116202138534605945375&rtpof=true&sd=true
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: