Over four articles, we have moved from why container security needs a reasoning layer, through DockSec's architecture, hands-on scanning, and CI/CD enforcement. This final article steps back to the program level: how the security score actually works, which metrics are worth tracking, and how an OWASP-governed, bring-your-own-model tool fits into a real security practice.
The security score, demystified
DockSec reduces a scan to a single 0-100 number with a rating from POOR to EXCELLENT. A single number is powerful—it fits in a dashboard, trends over time, and gives non-specialists something to rally around—but only if you understand what it does and does not mean.
There are two ways the score is produced. When a language model is configured, it can generate a holistic score from a summary of the findings. When no model is used—in --scan-only mode or with --skip-ai-scoring—a local, deterministic calculator produces the score instead. For metrics you intend to trend over time, the local score is usually the better choice precisely because it is deterministic: the same inputs always yield the same number, so a change in the score reflects a change in your container, not variance in a model's judgment.
The local score is a weighted blend of three axes:
-
Dockerfile quality, derived from Hadolint lint results
-
Vulnerability burden, a severity-weighted deduction over the normalized findings—criticals cost far more than lows
-
Configuration, derived by reading the Dockerfile directly and deducting for concrete, high-signal misconfigurations: running as root, credential-looking environment variables, unpinned or latest base images, missing health checks, sensitive exposed ports, ADD over COPY, and privileged flags
Two design decisions are worth calling out because they reflect hard-won lessons. First, when no image was scanned and there is genuinely no vulnerability data, the vulnerabilities axis is not silently treated as a perfect score; its weight is redistributed to the axes that were actually measured, so the number is not flattered by data that does not exist. But when findings do exist—including Compose misconfigurations with no image scan—that axis always counts. Second, hardcoded credentials cap the overall score outright.
A plaintext secret baked into an image is not the kind of issue that should be averaged into a comfortable middle; if DockSec finds one, the score reflects it as the serious problem it is.
What the score is good for, and what it is not
Use the score as a trend line and a conversation starter, not as an absolute verdict. A move from 45 to 70 across a quarter is a real, legible signal that posture is improving, and it is something you can put in front of leadership. An absolute "we are at 82, therefore we are secure" is not a claim the score can support—no single number can. This is exactly why enforcement in CI is gated on --fail-on severity thresholds and structured findings rather than on the score: the gate needs a precise, defensible condition, while the score is for direction and communication. Use each for what it is good at.
Metrics worth tracking
Beyond the headline score, a container security program benefits from a small set of metrics that DockSec's output feeds directly:
-
Critical and high finding counts over time, per image—the clearest measure of whether remediation is outpacing new disclosures.
-
New findings per build, from baseline mode. This is the leading indicator: if new findings trend toward zero, your gate is holding and the team has internalized secure defaults.
-
Time-to-remediate, measured as how long a given finding persists across the baseline before it disappears. Long-lived findings are where debt accumulates.
-
Base image freshness. Docker Scout's updated-base-image suggestion is a recurring, high-leverage fix; a stale base is a systemic issue that individual CVE counts obscure.
-
Coverage. The percentage of images and Compose services actually being scanned. A great score on 10% of your fleet is not a great program.
The --json output and the JSON and CSV reports make all of these straightforward to extract into whatever dashboard you already use. The point is not to track everything; it is to track the few numbers that change behavior.
Adopting DockSec across a team
Technology adoption fails on process far more often than on capability. A few principles make DockSec stick.
Start with visibility, not enforcement. As covered in Part 4, run in observe mode first, surface findings through SARIF, and let the team see the landscape before anything blocks a build. Trust is built by showing, not by gating on day one.
Meet developers in their existing tools. SARIF puts findings inline on pull requests, and the plain-English AI remediation means a developer does not need to become a CVE expert to act. Lowering the expertise required is how you scale security past the security team.
Respect data boundaries explicitly. For regulated or air-gapped teams, the ability to run the entire pipeline locally—scanning plus AI remediation via Ollama, or scan-only with no model at all—is not a nice-to-have, it is the difference between adoption and rejection. Make that story clear to the teams for whom it matters.
Ratchet, do not big-bang. Baseline mode exists so you can turn on enforcement without a revolt. Accept today's debt, block what is new, and tighten over time. Incremental and reversible beats comprehensive and abandoned every time.
Why open source and OWASP governance matter here
Governance belongs in a technical series because, for a security tool, it is a security property and not just a licensing footnote.
DockSec is an OWASP Lab Project under the MIT license: no commercial tier withholding features, no telemetry, no lock-in. You can read exactly what it does, run it entirely within your own boundary, and choose your own model provider. The relevant comparison is not against the open-source scanners DockSec builds on, but against commercial platforms that offer comparable AI remediation only by hosting your image data on their infrastructure. DockSec delivers that class of remediation while leaving both your data and your model choice under your control.
Where the project is heading
The roadmap pushes toward broader coverage and deeper CI integration—Kubernetes manifest scanning, software-bill-of-materials (SBOM) output, an offline advisory database, and further parity with sibling OWASP tooling. Because the architecture is built around a single results contract and a provider abstraction, these extensions are additive rather than disruptive—and because the project is open source, the roadmap is genuinely open to contribution.
Closing the loop
We began this series with a simple observation: container security does not fail for lack of scanners, it fails at the last mile, where a list of findings has to become a change someone actually makes. Everything DockSec does—the AI remediation layer, the single security score, the SARIF and baseline machinery, the bring-your-own-model design—serves that last mile.
Detection was never the hard part. Turning detection into action, at the scale of every Dockerfile and every build, is. That is the problem worth solving, and it is the one DockSec exists to solve.
This is the fifth article in a five-part series. Read the others here:
Part 4: Shift-Left—Gating, SARIF, and Baselines in CI/CD
Part 3: Hands-On Scanning—Dockerfiles, Images, and Compose
Part 2: Inside DockSec—Architecture and Pipeline
Part 1: Why Container Security Needs an AI Layer
