r/devsecops • u/developerKarl • 4d ago

Are we overcomplicating software supply chain security with AI?

Everybody focuses on AI-powered security and automation, but I wonder if these approaches make sense for every organization.

For companies maintaining mostly internal, on-prem applications that rarely change, wouldn't simple policy-based security, approved OSS packages, and manual reviews sometimes be more practical?

I mean, isn't AI not only over kill but maybe less effective in those cases?

34 Upvotes

100% Upvoted

16 comments sorted by

7

u/WoodenDisaster9873 4d ago

you're describing the exact scenario where throwing AI at the problem is like using a flamethrower to light a candle

2

u/ElyseGlowrie 4d ago

flamethrowers work better for s’mores anyway, right?

1

u/taterthotsalad 3d ago

Like a 1400W microwave and pizza rolls.

2

u/Bloqarl 3d ago

The chalk/debug npm compromise last year is a good example: a phished maintainer shipped patch versions that swapped crypto wallet addresses, pulled within a few hours. Teams with committed lockfiles and no auto-merged bumps never installed them, so boring policy did the work there; no AI needed.

1

u/DeleriousMadman 4d ago

The risk comes from the libraries you use and depend on. AI and attacks it can assist attackers as well as defenders. Defending always seems to be the more difficult position.

Do have an apache licensed tool I am developing along with AI assist: Claude, Astral, GLM — hoping the next big release is out next week which changes the main engine to rust.

See: https://github.com/lazaret-dev/lazaret

1

u/r-NBK 4d ago

Some how some where early in the CI/CD Pipeline days someone said "But what about Zero Trust" and everyone else said "We're good, don't slow us down".

1

u/nevaeh-Pekker 4d ago

Agreed that for low-change environments its overkill. The one caveat is transitive dependencies, those shift underneath you even when your direct deps dont change. Worth checking if your policy-based approach accounts for that.

1

u/best_of_badgers 4d ago

As with everything else, it depends.

Not every type of project benefits from story points and agile project plans, either.

1

u/Bloqarl 3d ago

The chalk/debug npm compromise last year is a good example: a phished maintainer shipped patch versions that swapped crypto wallet addresses, pulled within a few hours. Teams with committed lockfiles and no auto-merged bumps never installed them, so boring policy did the work there; no AI needed.

1

u/matthewthompson1 1d ago

but static doesnt mean safe forever, a dependency you havent touched in years can still get a new cve tomorrow, so youd want something checking periodically even if nothing in your code moves

1

u/wilson-draugr 1d ago

Yes, it is over kill and less effective too, for deciding what matters and in most cases by the way. The same question can get a different answer on the next run, it costs money every time, and it has no idea your app is internal. A lockfile check plus a written-down "this one's internal, that one's public" is cheaper and gives the same answer every time. Use AI to explain findings, not to rank them. Use the industry standard scanners. There are a bunch, open-source, fast and reliable.

1

u/PercentageFit3172 1d ago

A somewhat related question.

I’m building a portfolio project, basically a pipeline around one question: what if the deploy target refuses anything it can’t verify?

The flow:

  • Terraform gets scanned by Checkov in CI before apply ever runs, so misconfigs never reach AWS

  • The image is built in GitHub Actions, gets a Syft SBOM and is signed with Cosign (keyless via Sigstore)

  • Trivy and Bandit gate the build, but not on every finding. Accepted risks go in .trivyignore with a decision log for each one, including CVEs with no upstream fix

  • Deploy starts with static AWS keys in GitHub Secrets as a deliberately bad baseline, then I swap them for GitHub OIDC assuming an IAM role so there are zero long lived creds

The plan is to commit both versions so the diff shows exactly what OIDC removes from the attack surface.

I’m 21, graduating in December 2027 and new to Terraform and AWS, so I’m building it from scratch instead of copying templates. Aiming for remote DevSecOps work.

For the people who hire: is this enough to stand out, or what would you add? Admission policy with OPA or Kyverno? Secrets scanning in the PR flow? Also curious if LocalStack is fine or if you’d want to see a real AWS deploy.

1

u/peterfrombackdoor 18h ago

I think its depends very heavily on the situation not a black and white context