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.
- Scan the current code and the full git history. Deleting a secret in a later commit does not remove it from history.
- For every real secret found, rotate it first. Removing it from code comes second.
- Add secret detection to pull requests so new leaks are caught before merge.
- 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
- OWASP Top 10:2025 (read 2026-11-14)