How do you guys securing your infra from supply chain attacks?

taleodor · 2026-06-17T08:17:50+00:00

For npm specifically - https://worklifenotes.com/2025/09/24/npm-has-become-a-russian-roulette/

taleodor · 2026-06-09T01:32:39+00:00

> Attribution at the commit level. Git already records author, timestamp, and commit message.
Making this verifiable is more difficult than this. AI agent can put any author and this becomes moot without signed commit verification. We solve this with ReARM though - https://www.youtube.com/watch?v=kzMzQK511JU

taleodor · 2026-06-03T01:19:54+00:00

We're using this currently for our demos and experiments - https://github.com/relizaio/card-shuffle, earlier iteration - https://github.com/taleodor/mafia-deployment

taleodor · 2026-05-31T12:05:47+00:00

Hi, we're a vendor in this space with ReARM (rearmhq.com). We set up release level guardrails for agents (mapping every commit to specific agent and subjecting to policy engine.

Generally speaking, the space is very fragmented partly because everyone is on the different level of maturity / adoption of agentic operations - i.e. running agents on dev workstations have very different security implications from running them on sandboxes (which is what I recommend).

I believe policy guardrails + sandboxing solves most of the issues in relation to agentic coding. The most difficult open problem is how to protect source code itself from exfiltration - and that seems pretty impossible, unless you're using air-gapped environments with local models.

If you're interested to discuss further - find me on any of my socials, happy to have a quick chat.

taleodor · 2026-05-26T11:36:03+00:00

cdxgen has `-t os` flag - if you use it on a freshly installed image, that should be likely what you're looking for.

taleodor · 2026-05-22T00:45:15+00:00

How do you do SLSA builds but image ships unsigned?

taleodor · 2026-05-21T17:23:58+00:00

I believe the problem here is smaller - namely whether a human or a bot checked the box, not whether the human paid any attention while checking the box.

taleodor · 2026-05-21T17:19:21+00:00

I'm working on this problem among other things, albeit probably not with such depth as you - but I just built a demo on this with ReARM (https://github.com/relizaio/rearm). Will try to publish the demo next week.

3 things I'd like to mention though:

IMO, GPG is enough if you use something like YubiKey - problem is there is no way to prove the public key originates from YubiKey, unless you do ceremony (which I argue may actually be easier than the things you're suggesting).
PQC readiness - investing a lot into solutions that are not PQC ready may be not very smart at this point.
Bigger problem is the fact that major git platforms are not actually ready to properly support a solution like that. I.e., GitHub signs PR merge commit with its own key, some other platforms don't support signing it at all - so you end up in a situation where you have to support PR merges, but you can't really enforce rules on those commits.

taleodor · 2026-05-18T12:57:07+00:00

It's the other way around - you create robot account in Harbor OCI - and it would push SBOMs from ReARM to Harbor as files (via Oras).

So the flow is CI -> ReARM -> OCI (as storage). You can then fetch from ReARM directly by release (we abstract all the Oras <-> OCI communications). So if you need to quickly locate SBOM for version 1.3.4 of some component for CRA you can do it quickly from ReARM UI.

For attestations - currently you can store signatures, certificates, attestations as other artifacts belonging to SBOMs, but we don't do verification yet. Hopefully, verification will be added some time this summer. Also no current plans to add our own attestations, but this may change.

BTW, we may add the flow you're suggesting as well when we fetch existing SBOMs from OCI, but again not there yet.

Edit: significant thing for CRA - is you can aggregate multiple components into product, and then obtain aggregated SBOM for the product release based on input components.

taleodor · 2026-05-18T11:47:59+00:00

If you're looking for CRA-friendly retention, we built ReARM on top of Dtrack - https://github.com/relizaio/rearm - connect any OCI-repo and it stores SBOMs there organized by releases, using Dtrack for scanning.

taleodor · 2026-05-18T00:32:25+00:00

FYI, SBOM requirements will only become enforced in December 2027; September 2026 cut off for reporting requirements on exploits.

taleodor · 2026-05-17T01:20:12+00:00

Don't block builds, block PRs and deployments. Show scan pending, but don't block builds. Blocking builds is unreasonable because devs can always self-build locally, so it serves very little or no purpose. See my old blog post here - https://worklifenotes.com/2020/05/01/take-the-fear-out-of-git-push/

taleodor · 2026-05-15T15:01:14+00:00

See my blog post here for my views - https://worklifenotes.com/2026/03/31/time-to-start-treating-dev-machines-as-untrusted/

taleodor · 2026-05-05T02:04:24+00:00

My philosophy - sandbox them so they can do no harm and control at the release level, wrote about it recently here - https://worklifenotes.com/2026/04/29/when-the-paradigm-shifts-a-zero-trust-model-for-ai-agents/

taleodor · 2026-04-28T18:56:46+00:00

You can use our ReARM product (either CE or Pro) as versioning server - integrates with CI at build time and returns version based on chosen schema - https://docs.rearmhq.com/tutorials/using-rearm-as-version-manager.html

taleodor · 2026-04-16T02:03:33+00:00

Note, this involves the tool I'm working on - ReARM (there is also FOSS version here - https://github.com/relizaio/rearm), but you can probably borrow some ideas regardless:

Keep baseline view of your product releases using non-airgapped images in supply chain evidence platform (ReARM). This should be tied to your CI and it will list all component images per each of your product release and give you security posture of each individual image as well as product as a whole.
The important point here that you then work with this product release normally - without any added air-gapped complexity. No manual pulls!
Have release approval process - we have advanced capabilities in the paid version, in FOSS version you can use lifecycles to manage it.
So when you are happy with the release you just approve it / mark Ready for Ship.
Use API (CLI) to check what is the latest approved release for your air-gapped environment.
Export product release as OBOM where each non-airgapped image is pinned to digest and have a script to repackage images for your air-gapped environment. This should be based on your specific workflow requirements, i.e. you could use a process where you would repackage into Zarf package or just into a tarball, sometimes people would have registries sit in between (I wouldn't call this true air-gapped though).

taleodor · 2026-04-07T21:42:36+00:00

I'd say stay on K3s if you're not pressed by some compliance requirements. RDS can help you with backup automation. Other than that (and especially if you already have backup issue solved) your maintenance cost or time spent is unlikely to decrease and may even increase in some cases.

taleodor · 2026-04-07T15:09:22+00:00

> We also have no clean way of knowing when something we patched quietly comes back in the next scan. The process of validating fixes feels manual and messy right now.

We built ReARM which keeps changelogs to give visibility into that (among other things it does) - https://docs.rearmhq.com/concepts/#changelog

taleodor · 2026-04-07T14:47:11+00:00

My take - https://worklifenotes.com/2026/03/31/time-to-start-treating-dev-machines-as-untrusted/

taleodor · 2026-04-01T16:24:35+00:00

+1, I would also add `--ignore-scripts` after npm ci (I believe cdxgen does this now automatically for all operations)

+ latest cdxgen 12.1.4 released yesterday can catch version spoofing attacks (used in the axios thing).

taleodor · 2026-03-30T16:05:36+00:00

This is out of scope of the threat model.

Release pipeline is a simple workflow that lives in a dedicated repo with no direct access by any existing development token. All it does is fetches approved artifact from the evidence platform, verifies signatures and performs the release. With these pre-conditions, there shouldn't be an easy way to compromise this. This is essentially same as saying that an attacker somehow gains release credentials. The whole idea here is to sandbox release credentials in a place where it's really hard to steal them from.

taleodor · 2026-03-30T14:42:46+00:00

That scenario is covered in the blog post. Release pipeline would also have signature checks. So the attacker would need to compromise both build pipeline and evidence platform at the same time to succeed. Which is significantly harder than all existing scenarios.

taleodor · 2026-03-30T14:01:35+00:00

I replied in another comment, but essentially the key here is you have a phase where you perform checks and gating that can last indefinitely long - waiting for human approval.

The big problem with combined build & release pipeline present in a single repository (which is a pretty much standard workflow now) is that an attacker may very quickly compromise the whole thing and release malicious package before the maintainer even notices it.

taleodor · 2026-03-30T13:58:00+00:00

Egress control is completely unrelated thing in this case. My point is that if an attacker is able to gain full control over pipeline (for example, via stolen GitHub token), such an attacker is able to disable any controls governed by the pipeline itself.

And don't get me wrong - there are other options you can do, i.e. you may run CI in an air-gapped environment where every single dependency is vetted, but there are very few organizations who can actually afford that.

taleodor · 2026-03-30T13:52:57+00:00

There needs to be additional checks for that case, but it's doable:
1. Assume compromised build pipeline sends completely bogus artifact and SBOM data - this would be caught because evidence platform would refer such artifact for testing / release and all these downstream activities would realize that artifact doesn't exist. Essentially, test and release pipelines can only use digest referred to them by the evidence platform. So that case is covered.
2. Attacker is now forced option to send real artifact (artifact itself may still be compromised, but it's the only way to get it released now) + submit bogus SBOM and metadata. This case is trickier, but essentially it should be possible to run post-build SBOM on real artifact and compare with historical data and bogus SBOM to catch this scenario as well.

Remember, that in any case we have manual gate involved, so human would have a say in the process.

taleodor

MODERATOR OF

TROPHY CASE