Aanleiding
De controles in de wekelijkse jobs worden getoetst door ze weg te halen en te kijken of er een testgeval rood wordt. Voor een aantal controles gebeurt dat niet: ze kunnen verdwijnen zonder dat de testset iets merkt.
Effect
Zo’n controle kan bij een latere wijziging sneuvelen zonder dat iemand het ziet. De testset blijft groen en wekt de indruk dat het gedrag nog vastligt, terwijl dat niet zo is. Dat is precies het soort schijnzekerheid dat de controles moeten voorkomen.
Wenselijk gedrag
Elke controle die ertoe doet, heeft een testgeval dat rood wordt zodra de controle verdwijnt — of staat er met een expliciete vermelding dat hij niet te bereiken is.
Acceptatiecriteria
Technische details
In .github/workflows/check-upstream.yml (job apt-security-refresh), telkens gemeten door de regel te verwijderen en beide suites te draaien:
list-all-pkgs: true op de twee scanstappen — weghalen laat alles groen, terwijl de echte job strandt op "geen geïnstalleerde apt-pakketten". De testset leest de job-env al uit de workflow; de scan-inputs zouden op dezelfde manier uit de bron kunnen komen.
- De guard op een onleesbare basis-image uit de Dockerfile: geen geval manipuleert de
FROM-regel.
- De
grep_rc > 1-controles: terugzetten naar || true blijft groen.
- De waarschuwing "voorstel staat nog open terwijl de epoch over de drempel is": het pad wordt gelopen, de melding wordt niet gelezen.
- De
policy_opgehaald-vlag ("hoogstens één keer ophalen"): niets telt de aanroepen.
- Het uitsluitingsfilter op de upgrade-lijst: alleen de CVE-tak is gedekt.
In .github/scripts/apt-upgrade-beschikbaar.sh:
unique op de bevindingenlijst (bestaat om dezelfde bevinding op twee architecturen tot één rij terug te brengen) en sort -u op de pakkettelling: geen geval heeft dezelfde bevinding op twee architecturen of twee CVE’s op één pakket.
select(.pkg != null): geen geval heeft een bevinding zonder pakketnaam.
- De controle op een ontbrekende policy-uitvoer (alleen het ontbrekende bevindingenbestand wordt getoetst).
Twee guards zijn wel bekeken maar aantoonbaar niet via de testset te bereiken: de cijfervormcontrole op arch_count, en de lege-pakkettenlijst-arm (die impliceert altijd al aantal -eq 0). Die mogen als zodanig gemarkeerd blijven.
Aanleiding
De controles in de wekelijkse jobs worden getoetst door ze weg te halen en te kijken of er een testgeval rood wordt. Voor een aantal controles gebeurt dat niet: ze kunnen verdwijnen zonder dat de testset iets merkt.
Effect
Zo’n controle kan bij een latere wijziging sneuvelen zonder dat iemand het ziet. De testset blijft groen en wekt de indruk dat het gedrag nog vastligt, terwijl dat niet zo is. Dat is precies het soort schijnzekerheid dat de controles moeten voorkomen.
Wenselijk gedrag
Elke controle die ertoe doet, heeft een testgeval dat rood wordt zodra de controle verdwijnt — of staat er met een expliciete vermelding dat hij niet te bereiken is.
Acceptatiecriteria
Technische details
In
.github/workflows/check-upstream.yml(jobapt-security-refresh), telkens gemeten door de regel te verwijderen en beide suites te draaien:list-all-pkgs: trueop de twee scanstappen — weghalen laat alles groen, terwijl de echte job strandt op "geen geïnstalleerde apt-pakketten". De testset leest de job-env al uit de workflow; de scan-inputs zouden op dezelfde manier uit de bron kunnen komen.FROM-regel.grep_rc > 1-controles: terugzetten naar|| trueblijft groen.policy_opgehaald-vlag ("hoogstens één keer ophalen"): niets telt de aanroepen.In
.github/scripts/apt-upgrade-beschikbaar.sh:uniqueop de bevindingenlijst (bestaat om dezelfde bevinding op twee architecturen tot één rij terug te brengen) ensort -uop de pakkettelling: geen geval heeft dezelfde bevinding op twee architecturen of twee CVE’s op één pakket.select(.pkg != null): geen geval heeft een bevinding zonder pakketnaam.Twee guards zijn wel bekeken maar aantoonbaar niet via de testset te bereiken: de cijfervormcontrole op
arch_count, en de lege-pakkettenlijst-arm (die impliceert altijd alaantal -eq 0). Die mogen als zodanig gemarkeerd blijven.