When I saw the tj-actions attack, I decided it was time to finally implement action wrapping with our `witness-run-action`. This will generate signed attestations on exactly what the actions are doing.
We have some more testing to do before we cut an official release, but it is working correctly for the limited cases we have tested it with. I'd love this group's feedback.
I've been thinking about this a lot. First, the author should replace security with compliance. Currently they are two different things. There is a huge divide between compliance teams and developers, they speak completely different languages. I'm writing an entire series about it. I do think we can fix the problem, but it is going to be a lot more work than it was to get development and operations on the same page.
We would love for you to talk about this at one of our in-toto community meetings. Let me know if you are interested. contact info is in the comments, or feel free to stop by #in-toto on CNCF slack
Provenance is NOT injecting secret data into the build process. Provenance (scoped to supply chain security) is a document that describes the process in which the artifact goes through to become an artifact, to include all steps such as testing, GRC, etc.
Disclaimer, I am a member if the in-toto steering committee and the CEO of a software supply chain startup, Testifysec. https://github.com/in-toto/witness is our project
The context here is signed build provenance, which does involve injecting a secret (or more accurately, some publicly verifiable credential that only an a priori trusted party can mint or otherwise issue for) into the context that the provenance belongs to.
You're right that provenance itself doesn't require this, but that is principally because it punts on the problem of authenticity. Whether or not authenticity matters probably depends on the value and scope of the provenance's use :-)
I think if we can sufficiently isolate the build process we can solve this problem. Lot's of opportunity with our project Witness to add extra isolation. It is something we are working on. However, the real supply chain security "business problem" is just tracking everything in a standardized way. This is what the in-toto project helps with. I wrote about it here: https://www.cncf.io/blog/2023/08/17/unleashing-in-toto-the-a.... we also wrote Witness and Archivista to help solve this problem..
We have lots of work to do. https://github.com/in-toto/witness
Full disclosure, I am a member of the steering committee for in-toto and the CEO of TestifySec which is the main contributor to Witness.
how much experience you have with embed? from small iot white label like small business alarm systems to behemoths like Samsung... the only constant is they ship whatever and the lowest interns handle build
Step one is actually wanting to improve security. Those IoT companies have no motivator. Most of our business is with Federal/Defense and Finance. Those companies will only change if liability changes or the regulatory environment forces them to.
I think this type of attestation gets us part of the way there, however, the solution needs to be a bit more generalized to cover all the threats. At TestifySec we are working on a open source pluggable attestation framework with a rego policy engine for verification.
A review attestation (as proposed in this article) is pretty interesting and is an attestor I will probably add to our project.
Start doing security what way, exactly? I defined a threat model and a mitigation. And it's pretty straightforward - a single keypair that ties environment variables to their deployment.
The article you linked to is about signing. It doesn't solve "I need to put an AWS key into the environment of a process".
We have some more testing to do before we cut an official release, but it is working correctly for the limited cases we have tested it with. I'd love this group's feedback.
https://github.com/testifysec/witness-run-action/tree/v1.0.1...