audit notes work completed, test fixes work (95% done), new sprints, new data sources setup and configuration
This commit is contained in:
master
@@ -0,0 +1,55 @@
|
||||
Archived: 2026-01-14. Sprint sync: docs/implplan/SPRINT_20260112_001_DOCS_audit_evidence_pack_gaps.md\n\nHere’s why this matters right now: leading regulatory frameworks and supply‑chain security practices are converging on **audit‑ready evidence packages that are cryptographically verifiable, traceable, and retention‑fit for rules like NIS2, DORA, and ISO‑27001**.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
At the core of modern supply‑chain assurance is a **standards‑first stack** that lets you prove *what* ran, *how* it was built, *when* it existed, and that nothing was tampered with — without involving live systems during an audit. This aligns with risk‑based audit trails regulators increasingly expect.
|
||||
|
||||
**SBOM + VEX:**
|
||||
|
||||
* A **CycloneDX SBOM (1.6)** documents all components in a build — the baseline inventory an auditor will ask for. ([cyclonedx.org][1])
|
||||
* **OpenVEX** expresses contextual vulnerability exploitability data tied to those components, reducing noise and prioritizing real risks. ([cyclonedx.org][1])
|
||||
|
||||
**Attestation & Provenance:**
|
||||
|
||||
* **in‑toto** defines a signed **attestation framework** for each step of your supply chain, including custom or standard predicates. ([SLSA][2])
|
||||
* **SLSA Provenance** captures *how* the build was performed and ties source to artifact, making builds verifiable end‑to‑end. ([SLSA][2])
|
||||
|
||||
**Transparency & Timestamps:**
|
||||
|
||||
* Use **Rekor’s transparency logs** to record signatures and attestations immutably and publicly — essential for reproducible audit proofs and tamper evidence. ([blog.sigstore.dev][3])
|
||||
* Anchor artifact existence with **RFC‑3161 timestamps** from a trusted TSA to prove *the time* evidence existed, a requirement in keyless signing and transparency contexts. ([goteleport.com][4])
|
||||
|
||||
**Immutable Storage & Chain‑of‑Custody:**
|
||||
|
||||
* Store artifacts, logs, and attestations in **immutable/WORM storage** (e.g., S3 Object Lock or Azure immutable blobs) so you can *prove* retention and non‑modification over time — a practical audit safeguard that fits both ISO‑27001’s risk‑based expectations and DORA’s retention principles. ([Ignyte][5])
|
||||
|
||||
**Regulatory Alignment:**
|
||||
|
||||
* **ENISA’s NIS2 guidance** emphasizes robust supply chain risk management and traceability — good practice for SBOM, vulnerability context, and supplier security evidence. ([ENISA][6])
|
||||
* **DORA RTS** stresses operational resilience and evidence retention based on risk and business needs, with seven‑plus years typical in financial contexts. ([European Commission][7])
|
||||
* **ISO‑27001** doesn’t dictate specific retention periods, but it *requires defined documented retention, storage protection, and traceability of records mapped to controls* — exactly what an evidence pack built this way provides. ([Sprinto][8])
|
||||
|
||||
**Practical evidence pack structure:**
|
||||
Deliver auditors a **signed archive** with:
|
||||
|
||||
* **index.json manifest** listing all artifacts, Rekor entry IDs, and timestamps.
|
||||
* **proof artifacts** (e.g., binary diff reports, hash pairs) tied to SBOM/VEX/provenance.
|
||||
* **audit checklist** showing exact cosign/rekor verify commands, RFC‑3161 timestamp checks, and steps to validate immutability in object storage.
|
||||
|
||||
This transforms your supply‑chain record from ad‑hoc files into a *replayable, cryptographically anchored audit trail* regulators and auditors can verify without needing access to your live infrastructure.
|
||||
|
||||
[1]: https://cyclonedx.org/capabilities/vex/?utm_source=chatgpt.com "Vulnerability Exploitability eXchange (VEX)"
|
||||
[2]: https://slsa.dev/blog/2023/05/in-toto-and-slsa?utm_source=chatgpt.com "in-toto and SLSA"
|
||||
[3]: https://blog.sigstore.dev/its-ten-o-clock-do-you-know-where-your-private-keys-are-5c869cf53234/?utm_source=chatgpt.com "It's ten o'clock, do you know where your private keys are?"
|
||||
[4]: https://goteleport.com/docs/reference/machine-workload-identity/workload-identity/sigstore-attestation/?utm_source=chatgpt.com "Sigstore Workload Attestation"
|
||||
[5]: https://www.ignyteplatform.com/blog/iso-27001/iso-27001-record-retention/?utm_source=chatgpt.com "ISO 27001 Audit Record Retention Requirements"
|
||||
[6]: https://www.enisa.europa.eu/sites/default/files/publications/Good%20Practices%20for%20Supply%20Chain%20Cybersecurity.pdf?utm_source=chatgpt.com "Good practices for supply chain cybersecurity - ENISA"
|
||||
[7]: https://ec.europa.eu/finance/docs/level-2-measures/dora-regulation-rts--2024-1532_en.pdf?utm_source=chatgpt.com "dora-regulation-rts--2024-1532_en.pdf - European Commission"
|
||||
[8]: https://sprinto.com/blog/iso-27001-data-retention-policy/?utm_source=chatgpt.com "Data Retention Policy for ISO 27001: A Simple Guide ..."
|
||||
|
||||
@@ -0,0 +1,139 @@
|
||||
Here’s a quick, practical add-on for your pipelines: simple guardrails for AI‑assisted code so you don’t ship security/IP/license problems without slowing teams down.
|
||||
|
||||
---
|
||||
|
||||
# Why this matters (super short)
|
||||
|
||||
AI coding tools boost output but can introduce:
|
||||
|
||||
* **Security issues** (hardcoded secrets, unsafe APIs, prompt‑planted vulns)
|
||||
* **IP leakage** (copied proprietary snippets)
|
||||
* **License conflicts** (incompatible OSS brought by the model)
|
||||
|
||||
---
|
||||
|
||||
# Three fast checks (under ~1–3s per change)
|
||||
|
||||
1. **Secrets & Unsafe Patterns**
|
||||
|
||||
* Detect credentials, tokens, and high‑risk calls (e.g., weak crypto, eval/exec, SQL concat).
|
||||
* Flag “new secrets introduced” vs “pre‑existing” to reduce noise.
|
||||
* Require fix or approved suppression with evidence.
|
||||
|
||||
2. **Attribution & Similarity**
|
||||
|
||||
* Fuzzy match new/changed hunks against a vetted “allowlist” (your repos) and a “denylist” (company IP you can’t disclose).
|
||||
* If similarity > threshold to denylist, block; if unknown origin, require justification note.
|
||||
|
||||
3. **License Hygiene (deps + snippets)**
|
||||
|
||||
* On dependency diffs, compute SBOM, resolve licenses, evaluate policy matrix (e.g., **OK**: MIT/BSD/Apache‑2.0; **Review**: MPL/LGPL; **Block**: GPL‑3.0 for closed components).
|
||||
* For pasted code blocks > N lines, enforce “license/attribution comment” presence or ticket link proving provenance.
|
||||
|
||||
---
|
||||
|
||||
# Lightweight policy you can ship today
|
||||
|
||||
**Policy goals**
|
||||
|
||||
* Be **explainable** (every fail has a short reason + link to evidence)
|
||||
* Be **configurable** per repo/env
|
||||
* Support **override with audit** (who, why, for how long)
|
||||
|
||||
**Example (YAML)**
|
||||
|
||||
```yaml
|
||||
stellaops:
|
||||
ai_code_guard:
|
||||
enabled: true
|
||||
thresholds:
|
||||
similarity_block: 0.92
|
||||
similarity_review: 0.80
|
||||
max_paste_lines_without_provenance: 12
|
||||
licenses:
|
||||
allow: [MIT, BSD-2-Clause, BSD-3-Clause, Apache-2.0]
|
||||
review: [MPL-2.0, LGPL-2.1, LGPL-3.0]
|
||||
block: [GPL-3.0-only, AGPL-3.0-only]
|
||||
checks:
|
||||
- id: secrets_scan
|
||||
required: true
|
||||
- id: unsafe_api_scan
|
||||
required: true
|
||||
- id: snippet_similarity
|
||||
required: true
|
||||
- id: dep_sbom_license
|
||||
required: true
|
||||
overrides:
|
||||
require_issue_link: true
|
||||
max_duration_days: 14
|
||||
```
|
||||
|
||||
**Gate outcomes**
|
||||
|
||||
* ✅ **Pass**: merge/release continues
|
||||
* 🟡 **Review**: needs approver with role `SecurityReviewer`
|
||||
* ⛔ **Block**: only `SecurityOwner` can override with issue link + time‑boxed waiver
|
||||
|
||||
---
|
||||
|
||||
# Minimal evidence you store (per change)
|
||||
|
||||
* Hashes of changed hunks + similarity scores
|
||||
* Secret/unsafe findings with line refs
|
||||
* SBOM delta + license verdicts
|
||||
* Override metadata (who/why/expiry)
|
||||
|
||||
This feeds Stella Ops’ **deterministic replay**: same inputs → same verdicts → audit‑ready.
|
||||
|
||||
---
|
||||
|
||||
# Drop‑in CI snippets
|
||||
|
||||
**GitHub Actions**
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
ai-guard:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- uses: stella-ops/cli-action@v1
|
||||
with:
|
||||
args: guard run --policy .stellaops.yml --format sarif --out guard.sarif
|
||||
- name: Upload SARIF
|
||||
uses: github/codeql-action/upload-sarif@v3
|
||||
with: { sarif_file: guard.sarif }
|
||||
```
|
||||
|
||||
**GitLab CI**
|
||||
|
||||
```yaml
|
||||
ai_guard:
|
||||
image: stellaops/cli:latest
|
||||
script:
|
||||
- stella guard run --policy .stellaops.yml --format gitlab --out guard.json
|
||||
- test "$(jq -r .status guard.json)" = "pass"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Small UX that wins trust
|
||||
|
||||
* **Inline PR annotations** (secret types, API names, license rule hit)
|
||||
* **One‑click “request waiver”** (requires ticket link + expiry)
|
||||
* **Policy badges** in PR (“AI Code Guard: Pass / Review / Block”)
|
||||
|
||||
---
|
||||
|
||||
# How this plugs into Stella Ops
|
||||
|
||||
* **Scanner**: run the 3 checks; emit evidence (JSON + DSSE).
|
||||
* **Policy/Lattice Engine**: combine verdicts (e.g., *Block if secrets OR block‑license; Review if similarity_review*).
|
||||
* **Authority**: sign the gate result; attach to release attestation.
|
||||
* **Replay**: store inputs + rule versions to reproduce decisions exactly.
|
||||
|
||||
If you want, I’ll turn this into:
|
||||
|
||||
* a ready‑to‑use **`.stellaops.yml`**,
|
||||
* a **CLI subcommand spec** (`stella guard run`),
|
||||
* and **UI wireframes** for the PR annotations + waiver flow.
|
||||
Reference in New Issue
Block a user