Skip to content

The First 180 Days · Shipping Without Saying No: The First 180 Days in AppSec and AI Security

Chapter 6 of 14 · Weeks 2–4

Secrets, dependencies and the supply chain

  • How worried should I be about secrets in code?
  • We have thousands of dependencies. How do I manage that?
  • What does software supply chain security mean in practice?

Much of what your company ships is code it did not write: open source packages, container base images, build plugins and, increasingly, AI models. The OWASP Top 10:2025 lists Software Supply Chain Failures as its own category. That matches what most AppSec teams see day to day.

Secrets first

A leaked key is one of the few findings an attacker can use immediately, with no exploit to write. Start here because the fix is clear and the risk is concrete.

  1. Scan the current code and the full git history. Deleting a secret in a later commit does not remove it from history.
  2. For every real secret found, rotate it first. Removing it from code comes second.
  3. Add secret detection to pull requests so new leaks are caught before merge.
  4. Agree where secrets should live instead, and make that path easy to use.

Rule of thumb:Rotate, then verify the new secret works, then revoke the old one. Never revoke first. A rotation you cannot check is an outage you planned.

Dependencies

  • Know which packages each service uses. A lock file is the start of a software bill of materials.
  • Pin versions and review updates rather than pulling whatever is newest.
  • Watch for packages with names close to popular ones, and for packages that run install scripts.
  • Prefer fewer, well-maintained packages over many small ones that do one thing.

The question you might not ask out loud

Do I need to read the code of every package?

No. Nobody can. Focus on what is new, what runs at install time, what has very few maintainers and what sits on a sensitive path. Let tools watch the rest and alert you when something changes.

The path to production

Supply chain security also covers your own build. Can someone change a build step without review? Can a compromised plugin read every secret? Is what you deploy the same thing that was reviewed and tested? These questions connect back to the pipeline map from your first week.

You will not finish this in a month. Aim to have secret detection running, a plan for rotating anything found and a first dependency inventory for your most exposed services.

Write down who owns each of these jobs. Secret rotation often belongs to the service team, dependency updates to developers and the build to the platform team. Your role is to make the gaps visible, suggest the simplest fix and check back. A short weekly note on what changed keeps everyone moving without a meeting.

Sources

Practise it next

See what leaked keys and tokens look like in real code before you scan your own repositories.

Secret Scanner
Take this with you
Day 1: listen before you scan · The first 30 days · What if I screw up? · How am I doing? · Choose your own adventure: 180 days · Epilogue · Glossary

This button saves this chapter. The one-page edition saves the whole book.