colek42

Why do we need centralized CI? We just need a gate to make sure the code passes the right checks before we move the tip.

This is the wrong way to look at the problem. Maybe they should have asked, "Why does our process need to do so many git checkouts?" Why can't you just run the tests where you already checked out the code?

Thank you. Agree, that was not the intention

Using CI as a gate does not scale. We really think you need to push that testing to the local system and use something like pushgate.dev to validate that the agents actually ran the tests and generated provenance.

We kept pushing to GitHub. Pushgate.dev is a gitproxy. It forces your agents to run tests and validates them. We keep the happy path as fast as possible and use Cloudflare's infrastructure for high resilience. Full disclosure: I am the founder of TestifySec; Pushgate is a new product.

Thanks! Early days of pushgate.dev -- Reach out if interested; email in my profile

We are working on something here, pushgate.dev. It forces the agent to run tests; we are also working on adding support for static analysis of bundles using Jev. Onboarding is a bit of a mess right now, but send me a message cole@testifysec.com if you are interested.

CI needs to be decentralized, and the agents should run the test and verify the proof. This avoids all those API calls.

I'm working on something that removes CI completely and lets your agents certify their own tests. It is pretty rough right now but I'd love feedback -- pushgate.dev

I really wish they would support SPIFFE/SPIRE

In 2016 I was working for an organization that wanted a video streaming web app, but could not tolerate any latency. In the past, we solved this with an NAPI extension in Firefox. They removed this for good security reasons, but it left our users without an option. They would have to move to an electron app. Distributing this app and updating it across 1000s of terminals worldwide was not something we were set up to do. I hacked together something like this and could not believe how well it worked. The initial POC is here: https://github.com/colek42/streamingDemo.

There are ways to do it. Send me a message, and I can make an intro to the person we use.

We built https://aflock.ai/ (open source) to help with this. Constraining activity tends to work well

DSSE is great for this, if you need more schema use in-toto

We started a "science project" taking concepts from Multi Level Security to constraining AI agents. https://aflock.ai/. The idea is to have different data zones, and if an Agent accesses from a private zone, they should not be able to interact with the public zone.

We love Dapr's durabletask-go. https://pkg.go.dev/github.com/dapr/durabletask-go

Where is your line, copy editing, drafting, reorganizing? You are going to have a busy, boring, and angry life if you want to comment on every post that has signs AI touched it.

My job is to communicate quickly and clearly, AI helps me do my job faster and more efficiently. But thanks for telling me how I should do my job. You come off as both ignorant and arrogant.

That is quite an ignorant statement to make. I spent three years in combat, and am permanently disabled from my service.

Bingo, DoD does not want Anthropic to set guardrails on the technology it buys. If they don't want to abide they are free to deny service. We all know how that will turn our for them with the current administration. All while the DoD will just move to another provider that WILL abide. The only power really lies in whatever our elected officials want to do. Take the responsibility seriously.

The voters and congress tell the military how to use technology, not Anthropic. Shifting the decision to Anthropic takes away power from the citizenship.

Edit: The point is, go vote if you don't agree with what the administration is doing. Somebody will sell the DoD whatever they want no matter what Anthropic does.

We just built a new version of the witness run action that tracks the who/what/when/where and why of the GitHub actions being used. It provides "Trusted Telemetry" in the form of SLSA and in-toto attestations.

https://github.com/testifysec/witness-run-action/tree/featur...

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.

https://github.com/testifysec/witness-run-action/tree/v1.0.1...

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.

https://productgovernance.substack.com/publish/posts/detail/...

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.

in-toto is a great way to describe provenance. I talk about it in the CNCF blog article: https://www.cncf.io/blog/2023/08/17/unleashing-in-toto-the-a...

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

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 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.

Witness is a pluggable framework for software supply chain risk management. It automates, normalizes, and verifies software artifact provenance.

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.

I wrote some high level thoughts on attestation here: https://www.testifysec.com/blog/what-is-a-supply-chain-attes...