docs: Annex I deel I in kaart, plus de ontbrekende risicoafweging (#556) #600

Merged
brenno merged 1 commit from docs/cra-annex-i into main 2026-07-22 16:18:26 +00:00
Owner

Twee dingen, en het tweede was de echte bevinding.

Deel I in kaart

Het positiedocument mat tegen Annex I deel II, wat een bewuste keuze was. Het gevolg was dat deel I nergens stond terwijl dit project daar juist sterk is — precies wat de issue opmerkte. Nu staat het er in dezelfde driekolomsvorm, met de rechterkolom even serieus genomen als de middelste.

De rij die de issue als vermoedelijk zwakste aanwees, is dat ook: veilig verwijderen. DiskTraces ruimt op één plek op wat er van OciDeck op schijf achterblijft, maar het is unlink en geen overschrijving — en op een SSD met wear levelling is overschrijven óók geen garantie. Dat staat er zo, want de suggestie van veilig wissen zou schadelijker zijn dan de eerlijke zin.

De risicoafweging

Die ontbrak, en dat was het punt. Een dreigingsmodel vraagt "wie valt aan, langs welk pad" — dat hebben we. Een risicoafweging vraagt "wat kan er misgaan, hoe erg is dat voor wie het overkomt, en wat hebben we bewust aanvaard".

Dat laatste is waarom dit artefact moest bestaan: er stonden al drie aanvaarde afwijkingen in assurance/ (S3, loopback, PBKDF2) zonder kader waarin ze thuishoorden. Een aanvaard risico dat nergens als aanvaard staat opgeschreven, is over een jaar niet te onderscheiden van een vergeten risico.

Tien risico's, vijf aanvaard, elk met de voorwaarde waaronder het terug op tafel komt. Kans en gevolg staan grof (laag/midden/hoog) en dat is opzet — preciezere getallen zouden nauwkeurigheid suggereren die er niet is.

Het grootste risico is niet technisch. Het is R9: één beheerder, en dat is ook de enige regel in de tabel die door mensen verandert in plaats van door code.

Eén ding dat het schrijven opleverde en dat ik niet had voorzien: de weegschaal ligt hier anders dan bij gewone software, want de gevoeligste gegevens in het product zijn niet van de gebruiker. In een deck staan bevindingen over andermans systemen. Degene die het meeste risico loopt bij een fout, is niet degene die de knop indrukt. Dat verklaart achteraf waarom de privacyprojectie een compileertijdgrens is en geen instelling.

De tweede lens

Van het Eclipse Trustable Software Framework wordt niets als norm overgenomen. Het staat erin om de twee vragen die het stelt en onze poorten niet: doet het wat het zégt, en welke schade kan dit aanrichten. Bij de tweede hoort het eerlijke antwoord dat het ergste geval — een compleet pentestrapport bij de verkeerde persoon — geen technische oplossing heeft; alleen drie hulpmiddelen die het makkelijker maken om het goede te doen, en géén van drie een garantie.

Geregistreerd in assurance/README.md en aangehaald vanuit COMPLIANCE.md. make check groen.

Closes #556

Twee dingen, en het tweede was de echte bevinding. ## Deel I in kaart Het positiedocument mat tegen Annex I **deel II**, wat een bewuste keuze was. Het gevolg was dat deel I nergens stond terwijl dit project daar juist sterk is — precies wat de issue opmerkte. Nu staat het er in dezelfde driekolomsvorm, met de rechterkolom even serieus genomen als de middelste. De rij die de issue als vermoedelijk zwakste aanwees, is dat ook: **veilig verwijderen**. `DiskTraces` ruimt op één plek op wat er van OciDeck op schijf achterblijft, maar het is unlink en geen overschrijving — en op een SSD met wear levelling is overschrijven óók geen garantie. Dat staat er zo, want de suggestie van veilig wissen zou schadelijker zijn dan de eerlijke zin. ## De risicoafweging Die ontbrak, en dat was het punt. Een dreigingsmodel vraagt "wie valt aan, langs welk pad" — dat hebben we. Een risicoafweging vraagt "wat kan er misgaan, hoe erg is dat voor wie het overkomt, en wat hebben we bewust aanvaard". Dat laatste is waarom dit artefact moest bestaan: er stonden al drie aanvaarde afwijkingen in `assurance/` (S3, loopback, PBKDF2) zonder kader waarin ze thuishoorden. **Een aanvaard risico dat nergens als aanvaard staat opgeschreven, is over een jaar niet te onderscheiden van een vergeten risico.** Tien risico's, vijf aanvaard, elk met de voorwaarde waaronder het terug op tafel komt. Kans en gevolg staan grof (laag/midden/hoog) en dat is opzet — preciezere getallen zouden nauwkeurigheid suggereren die er niet is. Het grootste risico is niet technisch. Het is R9: één beheerder, en dat is ook de enige regel in de tabel die door mensen verandert in plaats van door code. Eén ding dat het schrijven opleverde en dat ik niet had voorzien: de weegschaal ligt hier anders dan bij gewone software, want **de gevoeligste gegevens in het product zijn niet van de gebruiker**. In een deck staan bevindingen over andermans systemen. Degene die het meeste risico loopt bij een fout, is niet degene die de knop indrukt. Dat verklaart achteraf waarom de privacyprojectie een compileertijdgrens is en geen instelling. ## De tweede lens Van het Eclipse Trustable Software Framework wordt niets als norm overgenomen. Het staat erin om de twee vragen die het stelt en onze poorten niet: doet het wat het zégt, en welke schade kan dit aanrichten. Bij de tweede hoort het eerlijke antwoord dat het ergste geval — een compleet pentestrapport bij de verkeerde persoon — geen technische oplossing heeft; alleen drie hulpmiddelen die het makkelijker maken om het goede te doen, en géén van drie een garantie. Geregistreerd in `assurance/README.md` en aangehaald vanuit `COMPLIANCE.md`. `make check` groen. Closes #556
docs(cra): breng Annex I deel I in kaart, en schrijf de risicoafweging
Some checks failed
CI / Gate (Linux) · Format · Analyze · Coverage (push) Failing after 5s
CI / Web hardening (push) Failing after 4s
CI / Docs links (push) Failing after 5s
CI / Supply-chain (Trivy · advisory) (push) Failing after 5s
CI / Gate (Linux) · Format · Analyze · Coverage (pull_request) Failing after 4s
CI / Web hardening (pull_request) Failing after 4s
CI / Docs links (pull_request) Failing after 4s
CI / Supply-chain (Trivy · advisory) (pull_request) Failing after 5s
CI / Test (macos-latest) (push) Has been cancelled
CI / Test (windows-latest) (push) Has been cancelled
CI / Test (macos-latest) (pull_request) Has been cancelled
CI / Test (windows-latest) (pull_request) Has been cancelled
b9df4aa94f
Het positiedocument mat tegen deel II, en dat was een keuze — dat deel zegt
inhoudelijk iets over kwetsbaarhedenbeheer. Het gevolg was dat deel I nergens
stond, terwijl dit project daar juist sterk is. Nu staat het er, in dezelfde
driekolomsvorm, met de rechterkolom even serieus als de middelste.

De rij die de issue als vermoedelijk zwakste aanwees, is dat ook: veilig
verwijderen. `DiskTraces` ruimt op één plek op, maar het is unlink en geen
overschrijving — en op moderne opslag is overschrijven ook geen garantie. Dat
staat er zo, want de suggestie ervan zou schadelijker zijn dan de eerlijke zin.

De echte bevinding was dat de risicoafweging ontbrak. Een dreigingsmodel vraagt
"wie valt aan, langs welk pad"; een risicoafweging vraagt "wat kan er misgaan,
hoe erg is dat voor wie het overkomt, en wat hebben we bewust aanvaard". Dat
laatste is de reden dat het artefact er moest komen: er stonden al drie
aanvaarde afwijkingen in dit dossier zonder kader, en een aanvaard risico dat
nergens als aanvaard staat, is over een jaar niet te onderscheiden van een
vergeten risico.

Tien risico's, vijf aanvaard, elk met de voorwaarde waaronder het besluit terug
op tafel komt. Het grootste is niet technisch: één beheerder.

Plus de tweede lens die de issue vroeg. Van het Eclipse Trustable Software
Framework wordt niets overgenomen als norm; het staat er om de twee vragen die
het stelt en onze poorten niet: doet het wat het zegt, en welke schade kan dit
aanrichten. Bij het tweede hoort het eerlijke antwoord dat het ergste geval —
een compleet pentestrapport bij de verkeerde persoon — geen technische oplossing
heeft, alleen drie hulpmiddelen die het makkelijker maken om het goede te doen.

Closes #556
brenno merged commit 0741362d2e into main 2026-07-22 16:18:26 +00:00
Sign in to join this conversation.
No description provided.