concept 10 · process and DevSecOps

Process and honesty: threat model, DevSecOps, doctor and red-team

A security tool is worth as much as the process around it. The limits are declared honestly: CI becomes a gate (self-audit, SLSA, SHA pinning, CODEOWNERS), the doctor gives observability and the red-team validates adversarially.

In 30 seconds

The non-goals and residual risk are declared (the maintainer's account, the trusting-trust problem: a scanner cannot detect a backdoor in itself). Against that: the self-audit runs the pentest as a CI gate plus cargo audit and requires Cargo.lock; the release separates build from publish, requires a reviewer and attaches SLSA provenance; CODEOWNERS locks the critical paths. The nemesis-doctor gives the posture picture by check groups, and the red-team (pentest) proves the engine still detects.

The threat model declares scope and limits; CI becomes a gate with self-audit, SLSA and CODEOWNERS; the doctor gives observability and the red-team proves the engine still detects. — Honest threat model; CI becomes a gate (self-audit, SLSA, CODEOWNERS); the doctor observes; the red-team validates.

From scratch: the process concepts

Threat model is declaring what you defend, against whom, and what is out of scope; honesty about limits is worth more than a promise of total security. DevSecOps is embedding security in the build pipeline, not after. SLSA is a supply chain integrity framework: the provenance attestation proves an artifact came from a specific repo/commit/workflow. CODEOWNERS requires owner review on sensitive files. Red-teaming is attacking your own system on purpose to validate the defense. The doctor is the observability: a diagnostic that reports the real state of each layer.

Why it matters

A costly and noisy compromise is preferable to a silent one. None of these controls gives an absolute guarantee, and that is stated openly, but together they make a supply chain attack something that must pass through human review, provenance and a gate that proves the scanner still works. The honest thing is to own the residual risk (the maintainer's account, trusting-trust) and design to raise the attack's cost, not pretend it does not exist.

How it correlates

The threat model defines the target; the self-audit and the release impose the gate; CODEOWNERS closes the "malicious PR merged without review"; the doctor observes; the red-team validates. It is the same principle as group 9 applied to the project itself: layers that reinforce each other, with honesty about what each one does not cover. And protecting Nemesis closes the loop of group 7 (the agent, and the repo, are threat surface).

How Nemesis applies it

The self-audit declares the limit in the file itself (trusting-trust: it does not self-validate) and therefore only holds coupled to CODEOWNERS plus branch protection:

📄 .github/workflows/self-audit.yml:10-17 · limite honesto declarado

# LIMITE HONESTO (trusting-trust): este workflow NAO se autovalida.
# Por isso SO vale acoplado a CODEOWNERS + branch protection (revisao humana
# obrigatoria nos arquivos trust-critical).

The pentest is the gate that proves the engine still detects:

📄 .github/workflows/self-audit.yml:85-89 · pentest como gate de CI

# GATE · Pentest do Nemesis deve estar APROVADO
bash .nemesis/pentest-nemesis-control/nemesis-defender/run-pentest.sh

The release separates build from publish, zeroes permissions by default and attaches SLSA provenance:

📄 .github/workflows/release.yml:8-16 · SLSA, draft, environment com reviewer

# permissions: {} global; build NAO pode publicar release.
# job 'release' num Environment com required reviewer; cargo build --locked
# attestation de proveniencia (SLSA): prova que o tarball veio DESTE repo/commit.

CODEOWNERS locks the paths that define security itself (a diff there could "blind" the scanner):

📄 .github/CODEOWNERS:18-21 · o motor de detecção sob revisão obrigatória

/.nemesis/nemesis-defender/src/   @feryamaha
/.nemesis/denylist/               @feryamaha
/.nemesis/hooks/                  @feryamaha

The doctor organizes the checks into groups (the modules compile, unit_tests, ebpf, daemon, scaffold, inventory, pentest), and --quick skips the heavy ones:

📄 .nemesis/nemesis-doctor/src/checks/mod.rs:3-9 e main.rs:10

pub mod compile;  pub mod daemon;  pub mod ebpf;  pub mod inventory;
pub mod pentest;  pub mod scaffold;  pub mod unit_tests;
// --quick: pula grupos pesados (G1 compile, G2 testes, G7 pentest)

Decisions and limits

The pentest numbers diverge between the repo sources: the run-pentest.sh header says "184 tests, 26 modules", while self-audit.yml and AGENTS.md cite "194/194". The script auto-detects and fails on any gap or false positive, so the number is dynamic; no value that could go stale is fixed here, and the divergence is pointed out. In the doctor, the code names G1 (compile), G2 (tests) and G7 (pentest); the other groups are described by the checks/ modules, with no invented label.

The self-audit does not self-scan the source: the scanner's code legitimately contains its own attack signatures, and self-scanning would give nearly 100% false positives. Content self-scan applies only to external content. And CODEOWNERS, draft and environment only take effect with branch protection enabled on GitHub; without it they are declared intent, and the material says so.

Self-check

▸What is the trusting-trust problem and how does it limit the self-audit?

A scanner cannot reliably detect a backdoor in itself. That is why the self-audit does not self-validate and only holds coupled to human review (CODEOWNERS + branch protection).

▸What is the difference between the checksum and the provenance attestation?

The .sha256 guarantees integrity (the file did not change). The SLSA attestation guarantees authenticity (the file came from this repo/commit/workflow). Integrity is not authenticity.

▸Why not fix the pentest test count in the material?