Scanners for images, code, infrastructure and secrets
One scanning layer across container images, source code, Terraform and Kubernetes manifests, and repository history, running in the pipeline and continuously against what is already deployed.
What is Scanners?
DevOpsArk scanners is the module that checks container images, application dependencies, source code, infrastructure-as-code definitions and repositories for vulnerabilities, misconfiguration and leaked secrets, both in the delivery pipeline and continuously against deployed artifacts.
What Scanners is for
The conditions this module removes. If none of these are familiar, you probably do not need it yet.
- Scanning happens at build time only, so an image that was clean in March is assumed clean in October.
- Four scanners produce four formats, four severity scales and four sets of duplicates.
- Infrastructure-as-code misconfiguration is found after it has been applied.
- Secrets committed to a repository stay in the history long after the file is deleted.
- Scan output is dumped into CI logs where nobody reads it.
Scanners run in two places. In the pipeline they check the artifact being produced (the image and its dependency tree, the source code, the Terraform plan and Kubernetes manifests, and the diff for committed secrets), and a policy gate decides whether the run continues. Continuously, they re-evaluate artifacts that are already deployed against newly published advisories, which is what catches the image that was clean when it shipped. All results land in one normalised model with a single severity scale, deduplicated across scanners and across services that share a base layer, so the count reflects distinct problems rather than repeated ones. Findings flow into vulnerability management, where they are prioritised by exposure and attributed to owners, rather than remaining as raw scanner output.
What Scanners does
The 7 capabilities that make up Scanners.
Container image scanning
OS packages and application dependencies checked against advisories, with the layer that introduced each finding identified.
Dependency and SBOM scanning
Direct and transitive dependencies resolved from lock files, with an SBOM stored per artifact for later queries.
Infrastructure-as-code scanning
Terraform, CloudFormation, Helm charts and Kubernetes manifests checked before they are applied.
Secret scanning with history
Repository content and full history checked for credentials, with verification of whether a found secret is still live.
Static code analysis
Source-level checks for injection, unsafe deserialisation, weak cryptography and similar classes, scoped to the diff on pull requests.
Continuous re-evaluation
Deployed artifacts are rechecked as new advisories are published, so yesterday clean image is today finding.
Deduplication across scanners
One normalised model and one severity scale, with findings that share a base layer collapsed rather than counted per service.
How Scanners fits together
Outcomes
- A vulnerability published after the build still gets found.
- One severity scale and one deduplicated list instead of four overlapping reports.
- Infrastructure misconfiguration is caught before it is applied, not after.
- A leaked credential is detected in history and checked for whether it still works.
- Scan results become tracked work items rather than CI log output.
Using Scanners, step by step
The path from connecting a source to getting value, in the order it happens.
- 1Scan in the pipeline
Image, dependencies, code and IaC are checked as part of the run.
- 2Apply the gate
Policy decides whether findings fail the build or record a warning.
- 3Normalise and deduplicate
Results are mapped to one model and collapsed across scanners and shared base layers.
- 4Re-evaluate continuously
Deployed artifacts are rechecked against new advisories.
- 5Route to management
Findings enter vulnerability management for prioritisation and ownership.
Where teams apply Scanners
Catch newly disclosed vulnerabilities in running images
Continuous re-evaluation flags deployed artifacts affected by an advisory published today.
Gate the pipeline on scan results
Fail a build on unresolved critical findings so a vulnerable image never gets a releasable tag.
Get findings on the pull request
See only what the diff introduced, rather than the whole repository backlog.
Answer a leaked-credential question
Find the commit, determine whether the credential is still valid, and rotate it.
What Scanners works with
Named integrations link to their own page. The rest are supported runtimes and formats.
Scanners: frequently asked questions
The 8 questions teams ask most often before adopting Scanners.
Container vulnerability scanning inspects a container image for known-vulnerable operating system packages and application dependencies by comparing what the image contains against published security advisories. Good scanning also identifies which image layer introduced each finding.
Build-time scanning checks an artifact against advisories known at that moment. Continuous scanning rechecks artifacts that are already deployed as new advisories are published, which is what catches an image that was clean when it shipped.
It checks Terraform, CloudFormation, Helm charts and Kubernetes manifests for insecure configuration (public storage buckets, permissive security groups, missing encryption, privileged containers) before the definition is applied.
Repository content and full commit history are checked for credential patterns. Deleting the file does not remove the secret from history, so history matters. Where possible DevOpsArk also verifies whether a discovered credential is still valid, which sets the urgency.
No. Results from existing scanners can be ingested and normalised into the same model alongside DevOpsArk own scanning, so you keep the tooling and gain deduplication, prioritisation and ownership routing.
Findings are normalised to one severity scale and deduplicated across scanners. Findings that come from a shared base layer are collapsed to one item affecting many services rather than counted once per service.
Yes, via a pipeline policy gate. Policy decides which severities fail the build, which record a warning, and whether an accepted risk with an expiry date allows the run to continue.
A software bill of materials lists every component in an artifact. Keeping one per image means that when a new advisory lands you can answer "which of our services ship this library" from an index in seconds rather than by rescanning the estate.
See Scanners against your own environment
A 30-minute walkthrough with a platform engineer, not a sales deck. Bring a cluster and a problem.