How DockSec Turns Container Security Scores Into Real Action

An OWASP-governed tool reframes the "last mile" problem in container security — converting scan results into changes developers actually make

Container security has long suffered not from a lack of detection tools but from a failure to act on what those tools find. On August 4, 2026, security researcher Advait Patel published the fifth and final installment of the DockSec Series on SecureWorld, pulling the lens back from technical implementation to examine how security scoring works, which metrics matter, and how teams can realistically adopt an open-source AI-assisted container security tool at scale.

The series has built steadily toward this program-level view — covering architecture, hands-on scanning, and CI/CD enforcement in earlier installments. This final piece confronts the question that most security tooling quietly avoids: what does a security score actually mean, and how do you make it change behavior inside a real engineering organization?

---

How DockSec Calculates Its Security Score

DockSec produces a single 0-to-100 score rated from POOR to EXCELLENT. That simplicity is intentional. A single number fits on a dashboard, trends over time, and gives non-specialists a rallying point — but only when teams understand its construction.

The score can be generated in two ways. When a language model is configured, it produces a holistic score from a summary of findings. When no model is available — in --scan-only mode or with --skip-ai-scoring — a local deterministic calculator takes over. For long-term trending, the local score is generally the stronger choice. Because the same inputs always yield the same number, any movement in the score reflects a genuine change in the container rather than variability in a model's output.

The local score blends three weighted axes:

• Dockerfile quality, drawn from Hadolint lint results
• Vulnerability burden, a severity-weighted deduction where critical findings cost far more than low-severity ones
• Configuration, derived by reading the Dockerfile directly and penalizing high-signal risks such as running as root, credential-like environment variables, unpinned or "latest" base images, missing health checks, sensitive exposed ports, using ADD instead of COPY, and privileged flags

Two design choices stand out. First, when no image was scanned and vulnerability data genuinely does not exist, the vulnerability axis weight is redistributed rather than treated as a perfect score — preventing the number from being artificially inflated by absent data. Second, hardcoded credentials trigger an outright score cap. A plaintext secret baked into an image is not the kind of issue that should be averaged into a comfortable middle ground.

Patel is direct about what the score cannot do. "An absolute 'we are at 82, therefore we are secure' is not a claim the score can support — no single number can," he writes. CI enforcement in DockSec is gated on severity thresholds and structured findings rather than the score itself, precisely because enforcement requires a precise and defensible condition while the score serves direction and communication.

Understanding Score Limitations in Practice

This distinction — score as compass, thresholds as gate — matters more than it might initially appear. Security teams that conflate a comfortable headline number with actual risk posture create blind spots, particularly when coverage is partial or base images are stale. The score tells you which direction you're moving; structured findings tell you whether to stop a build.

For teams building out a broader security measurement strategy, understanding how vulnerability assessment frameworks quantify and prioritise risk provides essential context for interpreting what DockSec surfaces and how to act on it.

---

Metrics That Drive Container Security Programs

Beyond the headline number, Patel identifies a focused set of metrics that DockSec's output feeds directly and that are worth tracking over time.

Critical and high finding counts per image reveal whether remediation is outpacing new disclosures. New findings per build — surfaced through baseline mode — serve as the leading indicator: when new findings trend toward zero, the gate is holding and developers have internalized secure defaults. Time-to-remediate, measured by how long a finding persists in the baseline before disappearing, exposes where technical debt accumulates. Base image freshness remains a recurring high-leverage fix, since a stale base is a systemic issue that individual CVE counts can obscure.

Coverage may be the most underappreciated metric of all. The percentage of images and Compose services actually being scanned determines whether program-level claims mean anything. A strong score across 10 percent of a fleet is not a strong program.

Turning Output Data Into Dashboard Intelligence

DockSec's JSON and CSV report outputs make all of these metrics extractable into existing dashboards. The goal, Patel notes, is not to track everything but to track the few numbers that change behavior. Teams that instrument every available data point often find themselves with comprehensive visibility and no clear action — the opposite of what a working security program requires.

A practical starting point is to align DockSec's output metrics with the measurement categories already embedded in your existing cybersecurity risk management framework. When findings map cleanly onto governance structures that leadership already recognises, reporting becomes faster and remediation ownership becomes clearer.

---

Adoption Principles for Security and Engineering Teams

Technology adoption fails on process far more often than on capability, and Patel offers a set of principles designed to make DockSec stick across an organisation.

Start With Visibility, Not Enforcement

Running in observe mode first — surfacing findings through SARIF before anything blocks a build — builds trust by showing teams the landscape rather than gating on day one. This distinction is critical in organisations where security tooling has historically been introduced as a blocker rather than an enabler. Developers who encounter a new tool through a failed pipeline are rarely its advocates. Developers who see plain-English remediation guidance appearing inline on their pull requests often become them.

Meeting developers in existing tools matters equally. SARIF places findings inline on pull requests, and plain-English AI remediation means developers do not need to become CVE experts to act on what they find. Lowering the expertise threshold is how security scales past the security team itself.

Designing for Air-Gapped and Regulated Environments

For regulated or air-gapped environments, the ability to run the entire pipeline locally — including AI remediation via Ollama or scan-only mode with no model at all — is described not as a convenience but as the difference between adoption and rejection. Many commercial alternatives that offer AI-assisted remediation do so by routing image data through their own hosted infrastructure. For teams operating under data residency requirements or strict network controls, that trade-off is simply not available to them.

Container security in these environments sits within a broader set of cloud security controls and infrastructure best practices that govern how workloads are deployed, scanned, and maintained — and DockSec's local-first architecture is designed to fit within those constraints rather than work around them.

Ratchet Over Time Rather Than Enforce Everything at Once

Patel advocates a ratchet approach over a big-bang rollout: baseline mode exists precisely to accept existing debt, block what is new, and tighten over time. Incremental and reversible beats comprehensive and abandoned. This is not a concession to pragmatism — it is a recognition that security programs which demand immediate perfection tend to generate workarounds rather than compliance.

Governance, Licensing, and the Open-Source Advantage

On governance, DockSec's status as an OWASP Lab Project under the MIT license carries direct security implications. There is no commercial tier withholding features, no telemetry, and no lock-in. The relevant comparison is not against open-source scanners but against commercial platforms that offer comparable AI remediation only by hosting image data on their own infrastructure. DockSec delivers that class of capability while leaving both data and model choice under the user's control — a distinction with real consequences for procurement, compliance, and trust.

The OWASP Project Registry provides further context on the governance standards and maturity criteria that OWASP Lab Projects are expected to meet, offering assurance that DockSec's open-source status reflects structured oversight rather than informal maintenance.

What the Roadmap Signals About Architecture Decisions Made Today

The project roadmap points toward Kubernetes manifest scanning, software-bill-of-materials output, an offline advisory database, and deeper CI integration — all described as additive extensions rather than disruptive ones given the tool's provider abstraction architecture. Teams evaluating DockSec now should recognise that the extensibility is load-bearing. Integrations built today are unlikely to require rearchitecting when new capabilities arrive.

---

The series closes where it began: container security does not fail for lack of scanners. It fails at the last mile, where a list of findings must become a change someone actually makes. Security practitioners can apply these takeaways immediately — use the DockSec score as a trend line for leadership reporting rather than a compliance verdict, prioritise coverage metrics before optimising scores on a partial fleet, and adopt baseline mode to enforce incrementally without disrupting active development workflows.