Diff v2 → v3

  # Security Baseline: NSM Grunnprinsipper & EU Regulation
  
  > **When to use it:** when you need to know what "secure enough" actually means for a
  > Norwegian or EU-facing product — which regulation bites, when, and which concrete
  > engineering controls satisfy it. Reach for it when scoping security work, answering a
  > customer security questionnaire, preparing for CRA or NIS2/digitalsikkerhetsloven, adding
  > an SBOM, writing a vulnerability disclosure policy, or deciding how much hardening a
  > service warrants. Complements [[Red Team|Red Team: Four Adversaries, Kill-Chain or It's Locked]],
  > which attacks a system — this one tells you what to build in the first place.
  
  Two different things get called "security requirements": **frameworks** that tell you what
  good looks like, and **law** that tells you what you must do or be fined. Keep them apart.
  NSM's grunnprinsipper are the former; CRA and NIS2 are the latter.
  
  ## What actually applies to you
  
  | Regime | Who | Status / dates | Teeth |
  |---|---|---|---|
  | **NSM grunnprinsipper** v2.1 | Anyone; written for critical-function operators | Guidance, June 2024. Not law — but the basis sector regulators build on | None directly; cited in contracts and audits |
  | **Digitalsikkerhetsloven** | Norwegian essential/important entities | In force **1 Oct 2025** (implements NIS1) | Supervisory |
  | **NIS2** (via digitalsikkerhetsloven) | ~5 000 Norwegian entities, up from ~600 | NIS2-adapted amendments scheduled **1 Jul 2026**, registration deadline **1 Oct 2026**, sector audits from ~mid-2027 | Up to **4 %** of global turnover; ~3 MNOK cap for public bodies |
  | **Cyber Resilience Act** | Anyone placing "products with digital elements" on the EU market — including software | Reporting obligations **11 Sep 2026**; full obligations **11 Dec 2027** | Up to **€15 M or 2.5 %** of global turnover |
  | **GDPR** | Personal data | In force | Up to €20 M / 4 % |
  | **DORA** | Financial entities and their ICT providers | In force Jan 2025 | Sector supervisory |
  
  ⚠️ **Verify the NIS2 date before you rely on it.** Norway is EEA, not EU, so NIS2 must be
  incorporated into the EEA agreement before Norwegian implementation. That incorporation was
  still pending in mid-2026 and the 1 July 2026 target has slipped before. Check
  [nsm.no](https://nsm.no/) for the current position rather than trusting a table — including
  this one.
  
  The trap worth naming: **CRA scope is much wider than people assume.** It is not an IoT law.
  Commercially supplied software is a "product with digital elements". If you ship a SaaS
  product into the EU with any downloadable or on-premise component, assume you are in scope
  until a lawyer says otherwise.
  
  ## The engineering baseline — NSM's 21 principles
  
  Four categories, 21 principles, 118 measures. The value is the ordering: you cannot protect
  what you have not mapped, and category 1 is where almost everyone is weakest.
  
  ### 1. Identifisere og kartlegge
  
  | # | Principle | What it means in a repo |
  |---|---|---|
  | 1.1 | Kartlegg styringsstrukturer, leveranser og understøttende systemer | A written service catalogue: what this system does, who owns it, what it depends on |
  | 1.2 | Kartlegg enheter og programvare | Dependency inventory — this is your **SBOM**, and it is also a CRA obligation |
  | 1.3 | Kartlegg brukere og behov for tilgang | Documented roles and what each may reach |
  
  ### 2. Beskytte og opprettholde
  
  | # | Principle | Concrete control |
  |---|---|---|
  | 2.1 | Ivareta sikkerhet i anskaffelses- og utviklingsprosesser | Security in the SDLC: threat model at design, review gate before merge |
  | 2.2 | Etabler en sikker IKT-arkitektur | Segmentation, least privilege between tiers, no flat networks |
  | 2.3 | Ivareta en sikker konfigurasjon | Hardened, reproducible config as code; **secure by default** |
  | 2.4 | Beskytt virksomhetens nettverk | Deny-by-default ingress/egress |
  | 2.5 | Kontroller dataflyt | Know and constrain what leaves the system |
  | 2.6 | Ha kontroll på identiteter og tilganger | MFA, scoped tokens, no shared accounts, revocation that works |
  | 2.7 | Beskytt data i ro og i transitt | TLS everywhere, encryption at rest, managed keys |
  | 2.8 | Beskytt e-post og nettleser | SPF/DKIM/DMARC, CSP and security headers |
  | 2.9 | Etabler evne til gjenoppretting av data | Backups **you have restored from**, offline copy |
  | 2.10 | Integrer sikkerhet i prosess for endringshåndtering | Every change reviewed, logged, revertible |
  
  ### 3. Oppdage
  
  | # | Principle | Concrete control |
  |---|---|---|
  | 3.1 | Oppdag og fjern kjente sårbarheter og trusler | Automated dependency + container scanning, patch SLA |
  | 3.2 | Etabler sikkerhetsovervåkning | Structured audit logging with retention |
  | 3.3 | Analyser data fra sikkerhetsovervåkning | Alerts a human actually sees; logs nobody reads are theatre |
  | 3.4 | Gjennomfør inntrengingstester | Periodic pentest — see [[Red Team|Red Team: Four Adversaries, Kill-Chain or It's Locked]] |
  
  ### 4. Håndtere og gjenopprette
  
  | # | Principle | Concrete control |
  |---|---|---|
  | 4.1 | Forbered virksomheten på håndtering av hendelser | A runbook naming who decides, who communicates, who fixes |
  | 4.2 | Vurder og klassifiser hendelser | Severity scale mapped to legal reporting clocks |
  | 4.3 | Kontroller og håndter hendelser | Contain → eradicate → recover, with evidence preserved |
  | 4.4 | Evaluer og lær av hendelser | Blameless post-mortem feeding back into controls |
  
  That last one is the [[The Compounding Layer|compounding layer]] applied to security: an
  incident you do not learn from you have merely survived.
  
  ## CRA: the obligations that land on engineers
  
  Most CRA compliance is paperwork owned by someone else. Four parts are yours.
  
  **1 — SBOM.** Annex I Part II requires a machine-readable SBOM covering **at least top-level
  dependencies**, kept current for the entire support period. No format is mandated; use
  CycloneDX or SPDX, both of which market surveillance authorities recognise.
  
  ```bash
  # Generate in CI, attach to every release artifact — not a one-off document
  syft dir:. -o cyclonedx-json > sbom.cdx.json
  grype sbom:sbom.cdx.json --fail-on high
  ```
  
  The SBOM requirement lives inside the *vulnerability-handling* rules, which tells you the
  intent: it is an operational tool for answering "am I affected?" in minutes, not a document
  you file. If yours cannot answer that question, it is not doing its job.
  
  **2 — Secure by default.** The product ships with a secure configuration and a minimised
  attack surface, and can be reset to its original state. No default credentials. Nothing
  sensitive on by default. Debug endpoints off in production builds.
  
  **3 — Vulnerability handling as a lifecycle.** Remediate without undue delay, test and review
  regularly, and *publish* information about fixed vulnerabilities. A coordinated disclosure
  policy and a monitored contact are part of the obligation:
  
  ```
  /.well-known/security.txt
    Contact: mailto:security@example.com
    Policy: https://example.com/security-policy
    Preferred-Languages: no, en
    Expires: <ISO-8601, keep it in the future>
  ```
  
  **4 — The reporting clocks.** From **11 September 2026**, actively exploited vulnerabilities
  and severe incidents must be notified:
  
  | Deadline | What |
  |---|---|
  | **24 hours** | Early warning |
  | **72 hours** | Full notification |
  | **14 days** | Final report, after a corrective measure is available |
  
  Twenty-four hours is a *detection* requirement disguised as a reporting one. If you cannot
  tell that you are being exploited, the clock is already running and you do not know it. This
  is why 3.2/3.3 above are not optional.
  
+ ## OWASP Top 10:2025
+ 
+ The category list changed. **2025 is current** (announced Nov 2025, finalised Jan 2026) and it
+ is not the 2021 list people still review against — two categories are new and SSRF moved.
+ 
+ | ID | Category | Change since 2021 |
+ |---|---|---|
+ | A01 | Broken Access Control | Retained #1; **now absorbs SSRF** |
+ | A02 | Security Misconfiguration | Up from #5 |
+ | A03 | **Software Supply Chain Failures** | **New** — expanded from "vulnerable components" |
+ | A04 | Cryptographic Failures | Down from #2 |
+ | A05 | Injection | Down from #3 |
+ | A06 | Insecure Design | Down from #4 |
+ | A07 | Authentication Failures | Renamed from "Identification and Authentication Failures" |
+ | A08 | Software or Data Integrity Failures | Retained |
+ | A09 | Security Logging & **Alerting** Failures | Renamed — alerting is now explicitly in scope |
+ | A10 | **Mishandling of Exceptional Conditions** | **New** — failing open, swallowed errors, happy-path-only logic |
+ 
+ Check **A03 and A10 explicitly.** Neither existed as a category before, so any review process
+ carrying the old list forward has a structural blind spot there — not because reviewers are
+ careless, but because there was nothing to prompt them.
+ 
+ A03 is also where this baseline joins up: the CRA SBOM duty and NSM principle 1.2 are the same
+ control seen from three directions.
+ 
  ## Verification: OWASP ASVS 5.0
  
  Frameworks say what to achieve; ASVS gives you testable requirements. Version 5.0.0 (May 2025)
  is ~350 requirements across 17 chapters, up from 286 across 14, with passwords realigned to
  NIST SP 800-63, post-quantum considerations added, and outdated practices removed.
  
  - **L1** — deliberately lowered entry bar. The first layer of defence; where to start.
  - **L2** — standard practice for anything holding real data. **This is the default target.**
  - **L3** — high assurance, for systems where compromise is severe.
  
  Pick a level, write it in the constitution, and make it a review dimension rather than an
  annual audit. "We follow ASVS" with no level named means nothing.
  
  ## The recipe: what to actually add
  
  ```bash
  # Supply chain — in CI, on every build
  syft / cdxgen        → SBOM, attached to the release
  grype / trivy / osv  → fail the build on known-exploitable
  gitleaks             → secrets, on pre-commit AND in CI
  cosign               → sign artifacts, verify at deploy
  
  # Runtime
  TLS everywhere · deny-by-default egress · scoped short-lived tokens
  structured audit log: who, what, when, from where — with retention
  security headers + CSP · SPF/DKIM/DMARC on the sending domain
  
  # Paper that engineering owns
  /.well-known/security.txt      · coordinated disclosure policy
  incident runbook with the 24h/72h/14d clocks written into it
  restore-tested backups, with the date of the last successful restore
  ```
  
  ## Gotchas
  
  **Backups you have never restored are not backups.** Principle 2.9 says *gjenoppretting* —
  recovery — not *sikkerhetskopiering*. Record the date of the last successful restore drill; if
  it is blank, treat the control as failed.
  
  **Do not conflate NSM grunnprinsipper with compliance.** They are excellent engineering
  guidance and they are not law. Following all 118 measures does not make you NIS2-compliant,
  and being NIS2-compliant does not mean you followed them. Track the two separately.
  
  **The 24-hour CRA clock starts at awareness, not at triage.** "We were still investigating" is
  not a defence. Decide in advance who is authorised to file an early warning on incomplete
  information — that decision made at 02:00 during an incident is the wrong time.
  
  **Scope creep is a real risk here, in both directions.** Regulation is the one area where
  [[The Restraint Principle: YAGNI for Agents|restraint]] does *not* apply to safety controls —
  input validation, error handling, authorization, and audit logging are load-bearing. But it
  absolutely applies to compliance *machinery*: a bespoke policy-management system for a
  five-person team is over-building. Buy the boring thing or use a checklist.
  
  **Security theatre passes audits.** Logs nobody reads, an SBOM generated once and committed,
  a disclosure address routing to an unmonitored inbox — all of these satisfy a checkbox and
  none of them work. The test for every control: *what would tell us it failed?*
  
+ ## Automating it in the pipeline
+ 
+ The [`agentic` spec-kit extension](https://github.com/joexbayer/spec-kit-agentic) ships this
+ baseline as `templates/security-baseline.md` and acts on it:
+ 
+ - `/speckit.agentic.security` establishes the feature's trust boundaries, walks the Top 10:2025
+   against them, and appends the resulting controls to `tasks.md` as `SEC-*` tasks — in the same
+   phase as the code they protect, before implementation.
+ - `/speckit.agentic.verify` reviews the diff against the same list and treats a checked-off
+   `SEC-` task with no matching control as a blocker.
+ 
+ The point of both: **a control that is a task gets built; a control that is a review comment
+ does not.**
+ 
  ## See also
  
  - [[Red Team|Red Team: Four Adversaries, Kill-Chain or It's Locked]] — adversarial validation of what this baseline builds
  - [[The Compounding Layer]] — incident learnings that become enforced rules
  - [[Rails Production Playbook]] — deny-by-default conventions in a concrete stack
  - [NSM grunnprinsipper for IKT-sikkerhet](https://nsm.no/regelverk-og-hjelp/grunnprinsipper/) — the source, v2.1 (June 2024)
  - [Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act) and [CRA reporting obligations](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting) — European Commission
  - [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/) — v5.0.0, May 2025