Yes. Kubernetes manifests and Helm values are supply chain inputs because they choose which container images run, where they come from, and what access they get. A change to either can alter production as much as a code change, so they need an owner, a review and a known source.
What counts as a supply chain input
Most teams think of packages and base images first. A supply chain input is anything outside your own application logic that shapes what ends up running. By that definition, deployment files qualify:
- The image reference in a manifest picks the exact software that starts.
- Helm chart and subchart versions pull in templates written by other people.
- Annotations and labels switch behavior in controllers such as ingress and service meshes.
- RBAC objects define what a workload can do once it runs.
- Remote bases and referenced URLs pull configuration from outside your repository.
None of these are application dependencies in the package manager sense, so a dependency scanner reading lockfiles will not review them. That gap is the reason to treat them as their own input class.
Four questions to ask of each input
| Question | Example in a manifest repo |
|---|---|
| Where did it come from? | A vendor chart, a blog snippet, an internal template |
| Who owns it? | A team in a CODEOWNERS file, or nobody |
| How is it pinned? | Chart version, image digest, commit hash |
| Who reviews changes? | Required reviewers on the directory |
If any answer is "unknown", that input is a risk you have not named yet.
Where inputs sneak in
Copy and paste. A manifest copied from a tutorial brings its image, its permissions and its assumptions. Nobody reviewed it for your cluster.
Image tags. The Kubernetes documentation notes that tags can be moved to point at different images, while digests are fixed. A manifest that references a tag is trusting the registry to keep that promise.
Defaults. A chart that ships with a feature off, or a manifest that omits a security setting, is choosing a default on your behalf.
Automation. Bots that bump image tags and chart versions are useful and also write into your deployment repository. Their changes need the same review as a person's.
A minimal operating model
- Keep manifests and values in version control, one place per environment.
- Require a pull request and a reviewer for every change to those paths.
- Pin images by digest where you can, and chart versions always.
- Record the source of each third party chart in a short file next to it.
- Re-check the list on a schedule, because the owner of a chart can change and publishers can stop maintaining it.
None of this needs a new tool to start. It needs agreement on which files are inputs and who looks at them.
Where software scanning fits
Manifest review answers "what are we asking the cluster to run". Software composition analysis answers "what is inside what we run". You need both questions answered. Safeguard's dependency scanning, SBOM and reachability analysis help with the second question for the packages inside your images. They do not replace reading the manifests. You can start with the free scan.
Quick check
Does a dependency scan cover my Kubernetes manifests?
Not by itself. Lockfile and package scans cover packages. Manifests need their own review for images, permissions and exposure.
What is the cheapest first step?
Add required reviewers to the directory that holds deployment files, and pin chart versions.
Sources
Last reviewed: 19 October 2026.
