Risk Management #
How Deevnet decides what can go wrong, what to do about it, and what to accept. It replaces the earlier Security & Vulnerability Management stub: security is one kind of risk, alongside losing state, losing a device, and not being able to explain why something is configured the way it is.
Deevnet is a portable lab run by a small team on consumer hardware. The aim is not to eliminate risk — it is to know each risk, choose a treatment deliberately, and write the choice down, so nothing is a surprise.
The cycle #
| Step | What happens | Where it is written |
|---|---|---|
| Identify | a risk is noticed — in design, in a change, in an incident, from an advisory | an ADR’s consequences, a change record, an incident record |
| Assess | how likely, and how bad if it happens | the risk register |
| Treat | reduce it, transfer it, avoid it, or accept it — explicitly | a change record (reduce), an ADR (avoid/accept) |
| Review | is the treatment still right? | the register, when a related change or incident lands |
Accepting a risk is a legitimate treatment. Accepting it silently is not.
The areas #
Vulnerability Management
Tracking CVEs and advisories, checking code before production, and evaluating patches.
Security Controls
Segmentation, tenant isolation, encryption, and how credentials are held.
Traceability
How every decision and change can be traced from why, to what, to what happened.
Resiliency & Limits
What the hardware cannot do, the risks that accepts, and what holds it together instead.
Risk Register
The known risks, how each is treated, and the record that owns it.