Beveiliging testen voordat er iets uitgaat

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 de standaardbranch geslaagde statuscontroles vereist vóór een merge, zodat tests draaien voordat iets wordt uitgebracht in plaats van erna.
• GitHub · StandardOS leest of codescanning of een reviewpoort deel uitmaakt van wat de standaardbranch beschermt.
• AWS · StandardOS leest of ECR images scant voordat ze worden uitgerold.
• Snyk · StandardOS leest welke actieve projecten het testen van pull requests uit hebben staan, zodat een kwetsbare afhankelijkheid na het samenvoegen wordt gemeld in plaats van ervoor gestopt.

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.29 als behandeling noemen.

• Door een leverancier geschreven code komt ongecontroleerd in productieApplicatie

Wat klanten over deze maatregel vragen

Beveiligingsvragenlijsten gebruiken geen maatregelnummers. Dit zijn de vragen, zoals klanten ze stellen, die uitkomen bij A.8.29. 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.25, A.8.32

Waar dit onder NIS2 valt

A.8.29 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.