Why We Are Saying OWASP-Aligned, Not OWASP-Compliant

2026-06-04

There is a sentence every project is tempted to publish once its security work starts to feel serious:

We are now OWASP compliant

Developer Dashboard is not going to say that.

Not because the recent security work was small.

Not because the project is soft on security.

And not because this was only a light checklist pass.

The reason is simpler and stricter: the claim is too broad, too easy to misread and too easy to overstate.

What the project can now say is narrower and more defensible:

Developer Dashboard now enforces a full OWASP-aligned security gate.

That is a stronger sentence precisely because it is more exact.

If you have not read the latest platform updates yet, start here:

• What Changed Since Runtime Hardening, API Auth and Layered Skills Became Real
• What Changed Since "Routing, Collectors and Workspaces"
• What Changed Since "Layers, Context, Skills, Pages and Runtime"

The Important Distinction

OWASP is not one single universal pass/fail stamp for local developer tools.

When teams say "OWASP compliant", they often mean one of several different things:

• aligned to OWASP Top 10 threat categories
• assessed against OWASP ASVS at a stated level
• reviewed with OWASP testing ideas in mind
• externally audited against a documented scope

Those are not interchangeable.

If Developer Dashboard claimed blanket compliance without qualification, it would imply a more formal and more universal guarantee than the project can honestly defend today.

That is exactly the kind of language serious security work should avoid.

What Actually Changed

The recent work did not just add one line to documentation.

It turned OWASP alignment into a release gate with executable checks behind it.

1. OWASP is now a hard gate, not a friendly nod

Developer Dashboard now treats OWASP as a release and verification gate instead of a general intention.

That gate now covers:

• OWASP ASVS 5.x chapter coverage from V1 through V14
• OWASP Top 10 2021 threat mapping from A01 through A10
• Level 2 as the default minimum floor
• Level 3 review for higher-trust changes such as auth, sessions, cryptographic handling, release-signing paths and externally callable API routes

That is a much more serious posture than "we thought about OWASP while writing code".

2. The gate is executable

This is the part that matters most.

A lot of projects have security language. Far fewer have security language that fails when the repository drifts away from it.

Developer Dashboard now carries a dedicated regression test for the OWASP gate itself.

That test checks that the repository still includes:

• the full ASVS chapter span
• the full Top 10 span
• the Level 2 and Level 3 policy split
• the required audit commands
• the expected security-sensitive runtime invariants around redirects, cookies, headers, auth ownership and traversal coverage

That means the project is no longer relying on memory or good intentions to keep the security gate intact.

3. The runtime evidence behind the claim is visible

The gate is not just "mention OWASP somewhere".

It points at concrete evidence inside the repository:

• forbidden-library scans
• auth and session checks
• redirect sanitisation checks
• traversal-focused checks
• raw SQL grep checks
• focused web and SSL regression tests

That matters because security drift usually starts in the space between policy wording and what people actually verify.

This work reduces that gap.

4. The narrower claim is the stronger one

There is a useful paradox here: by refusing to claim universal compliance, the project can make a stronger technical statement.

Developer Dashboard is:

• OWASP-aligned
• ASVS-gated
• Top-10-mapped
• regression-tested at the repo gate level

That is more believable than a vague badge because it tells you what is actually being enforced.

What This Does Not Mean

This does not mean:

• every security question is solved forever
• the runtime has no future hardening left
• the project has a formal third-party certification
• every deployment context has been externally assessed

One obvious example is content security policy hardening. The project already sets useful security headers, but there is still a difference between "present and useful" and "as locked down as possible".

Security posture is not one commit. It is a standard that has to survive the next one too.

Why This Matters

Developer Dashboard is not trying to look secure in screenshots.

It is trying to become a local platform that can be trusted more seriously:

• by one operator on one laptop
• by layered project runtimes
• by browser-facing helper flows
• by machine-driven Ajax routes
• by release and packaging workflows

That requires security language precise enough to survive scrutiny.

So the project is choosing the sentence it can keep proving:

Developer Dashboard now has a full OWASP-aligned security gate.

That is not marketing inflation.

It is the start of a security posture the project can keep defending every time the repository changes.