Beveiliging door de hele manier waarop software ontstaat

Hoe StandardOS dit controleert

Alleen-lezen verbonden, volgens een schema. Een geslaagde controle houdt een bewijsregel vers; een mislukte laat hem verlopen, zodat een achteruitgang aan het licht komt in plaats van op de audit te wachten. Elke integratie, en wat elke set toegangsgegevens kan zien.

• GitHub · StandardOS leest of elke gecontroleerde repository een CODEOWNERS-bestand en een workflow onder .github/workflows draagt, de twee bestanden die een veilige ontwikkelcyclus achterlaat.

Risico's die deze maatregel behandelt

Uit het startrisicoregister dat StandardOS bij het inrichten voorstelt. U behoudt, bewerkt of verwijdert elk ervan; dit zijn de risico's die A.8.25 als behandeling noemen.

• Kwetsbaarheid geïntroduceerd in eigen softwareApplicatie

Wat klanten over deze maatregel vragen

Beveiligingsvragenlijsten gebruiken geen maatregelnummers. Dit zijn de vragen, zoals klanten ze stellen, die uitkomen bij A.8.25. Elke vraag wordt beantwoord uit dezelfde vier registraties: de VvT-status, het goedgekeurde beleid, gedateerd bewijs en een live controle. De volledige kaart van dertig onderwerpen.

• Volgt u een veilige ontwikkelcyclus met codereview en wijzigingsbeheer?

  Veilig ontwikkelen, codereview, wijzigingsbeheer, CI/CD · ook A.8.29, A.8.32

Waar dit onder NIS2 valt

A.8.25 is onderdeel van wat artikel 21, lid 2, onder e), Security in network and information systems acquisition, development and maintenance, vraagt. Het één keer invoeren telt voor beide, en dat is precies waarom de NIS2-mapping bestaat.