What should a security CLI include for SMEs and NIS2/DORA?

You’re absolutely right — SMEs don’t need another wall of JSON masquerading as “security.” The value is in fast interpretation, not just detection. In practice we’ve found that the sweet spot is dual-mode output:

• Machine-readable (SARIF/JUnit/JSON) so CI/CD, GitHub Actions, and auditors can ingest it automatically. • Human-readable summaries that tell a non-security person what this means and what to do next in <10 seconds.

Pass/fail thresholds tied to control objectives help a lot because SMEs rarely know whether a warning is “fix tomorrow” or “fix this quarter.”

We shipped ScortonJS CLI (MIT, 450 weekly downloads) to make security checks and EU compliance mapping runnable from the terminal. Supports: scan, audit, score; compliance (dora|nis2|both); report generation.

Goal: lightweight audits that emit a publishable markdown/PDF report for client reviews or insurance underwriting—no vendor lock‑in, clear pass/fail + score.

Quick start: npx scortonjs-cli scan <tool> <target> • npm i scortonjs-cli

Repo: github.com/scorton/scortonjs npm: npmjs.com/package/scortonjs-cli

Ask: Which signals and formats actually unblock you—code/deps/infra/behavior, and is SARIF/JUnit/SPDX enough?

For EU teams, what’s the minimum NIS2/DORA mapping you need to ship?

For SMEs, clarity and actionable output are the most important signals. Having a simple CLI that emits SARIF/JUnit for automated pipelines is great, but adding a minimal “human readable summary” with clear pass/fail thresholds and context for compliance checks can make a huge difference in adoption. Curious if you’ve considered automated mapping of dependencies to NIS2/DORA clauses, or if you leave that for post-scan review.