Dhahab · Open Source

DIRA درع

Security audit for startup codebases. One command, zero dependencies, free.

Secrets · dependency CVEs · 38 misconfiguration rules · license risk · git-history leaks · live TLS & headers · SBOM · security-readiness score

Get it on GitHub How to run it

dira scan . -t yourapp.com 
$ dira scan . -t yourapp.com

  SECURITY GRADE    F   risk 72/100
  STARTUP READINESS 38%  Early-stage gaps (30/80 pts)

  CRITICAL 2  HIGH 5  MEDIUM 11  LOW 6

  ─── CRITICAL ─────────────────────────────────────
  ● Stripe secret/restricted key
      src/lib/billing.ts:14  sk_l************XwEr
      → Revoke the key at the provider, issue a new one, move it to a
        secret manager, and purge it from git history.

  ● GitHub token found in git history (commit 8f21ac3)
      git history @ 8f21ac3
      → Deleting the file does not remove it from history — rotate now.

  ─── HIGH ─────────────────────────────────────────
  ● lodash 4.17.11 — CVE-2021-23337: command injection
      package-lock.json  npm:lodash@4.17.11
      → Upgrade lodash to 4.17.21 or later.

  ● Secret exposed through a public build-time env var
      .env.production:7  NEXT_PUBLIC_STRIPE_SECRET_KEY
      → Compiled into the JS bundle and readable by every visitor.

  Licenses  MIT ×29  BSD-3-Clause ×14  Apache-2.0 ×6  MPL-2.0 ×2

  418 files · 402 cached · 87 deps · 0.9s
Why it exists

Your first enterprise customer will ask. Better you find it first.

Startup security tooling is either a platform that costs more than your runway or five separate CLIs nobody ever wires up. So the leaked Stripe key sits in the repo until a security questionnaire, an acquirer's diligence checklist, or somebody else finds it.

DIRA is one command that answers the question founders actually get asked — is this codebase safe enough to sell to an enterprise? — and prints the exact fix beside every finding.

Want to walk the same ground by hand first? The free guide 18 things to fix before your first real user covers the checklist DIRA automates, with the why behind each item.

7Scanners
62Detection rules
0Dependencies
0.9sWarm re-scan
What it checks

Seven scanners, one pass

secrets

Leaked credentials

23 provider patterns — AWS, Stripe, OpenAI, Anthropic, GitHub, GCP, Slack, npm, database DSNs, private keys — plus an entropy-gated generic rule. Every value is redacted before it reaches a report.

deps

Dependency CVEs

Every package in your lockfiles resolved against OSV.dev — npm, PyPI, Go, crates.io, RubyGems. Free, batched, no API key, with the exact fixed version to upgrade to.

config

38 misconfiguration rules

Docker, Kubernetes, Terraform, GitHub Actions, cloud IAM, frontend code (NEXT_PUBLIC_ secrets, tokens in localStorage, XSS sinks) and LLM apps (browser-side provider keys, prompt concatenation, model output piped to an executor).

licenses

License risk

Each dependency's license resolved and classified — permissive, file-level copyleft, GPL, AGPL/SSPL. The finding that kills acquisitions, with an inventory for your diligence folder.

git

History leaks

Deleting the file does not rotate the key. DIRA reads commit diffs for secrets that were removed from the working tree but still live in history, plus tracked .env files and credentials in the remote URL.

surface

The live domain

TLS validity and expiry, HSTS/CSP/nosniff/frame-options, cookie flags, HTTP→HTTPS redirect, and whether /.env or /.git/config is being served to the internet.

readiness

Security-readiness score

Eighteen weighted checks modelled on SOC 2 and enterprise security questionnaires — CI, tests, secret scanning, SAST, CODEOWNERS, IaC, backups, incident response — rolled up into a percentage and a tier.

The differentiator

A readiness score, not just a bug list

Eighteen weighted checks modelled on what SOC 2 auditors and enterprise security questionnaires actually ask for: lock-pinned dependencies, automated updates, CI, tests, secret scanning, SAST, CODEOWNERS, a disclosure policy, infrastructure as code, error tracking, an incident-response plan, backups, privacy documentation.

You get a percentage, a tier, and the specific missing artifact — plus the manual attestations no scanner can verify for you (MFA enforcement, branch protection, least-privilege IAM, same-day offboarding). Then dira fix --apply writes the boring ones for you.

Run it

Three minutes to your first report

Scan

pipx install git+https://github.com/Yusuf-Gadelrab/dira@v1.2.0, then dira scan . — PyPI and npm packages are on the way.

Share

-f html -o report.html produces a client-shareable audit. -f sarif lands findings in GitHub's Security tab.

Gate

dira init installs the CI workflow and pre-commit hook. PRs scan only what changed; exit code 1 fails the build.

Fix

dira fix --apply writes the missing policy files and .gitignore rules, then prints the rotations only you can do.

Honest limits

What it is not

DIRA is automated pattern analysis. It does not replace a penetration test, a threat model, or a real SOC 2 audit, and it cannot see your cloud IAM, your MFA posture, or your access reviews — those are listed as manual attestations in the report.

A clean run means "no known bad patterns in this repository". It does not mean "secure".

Scanning a domain you do not own or have permission to test may be unlawful. The --target flag makes unauthenticated requests to a handful of well-known paths — point it at your own infrastructure only.

Your code never leaves your machine. The only network calls are anonymous package-name lookups to OSV.dev, npm and PyPI, and requests to a domain you name yourself. --offline disables all of them.

Scan your repo in the next five minutes

MIT licensed. Free forever. No account, no telemetry.

View on GitHub Ask me to run it for you

Not on GitHub yet?

Leave your email and you'll hear the day DIRA lands on PyPI and npm. One message, nothing else.

Used for this one announcement. Legal Privacy · all waitlists