Test sikkerheden før noget sendes ud

Sådan kontrollerer StandardOS det

Forbundet skrivebeskyttet, efter en plan. Et bestået tjek holder en bevispost frisk; et fejlet lader den udløbe, så en tilbagegang kommer frem i stedet for at vente på auditten. Hver integration, og hvad hver legitimationsoplysning kan se.

• GitHub · StandardOS læser om standardbranchen kræver beståede statustjek før et merge, så tests kører, før noget leveres, og ikke bagefter.
• GitHub · StandardOS læser om kodescanning eller en review-port er en del af det, der beskytter standardbranchen.
• AWS · StandardOS læser om ECR scanner images, før de udrulles.
• Snyk · StandardOS læser hvilke aktive projekter der har slået test af pull requests fra, så en sårbar afhængighed rapporteres efter merge i stedet for at blive stoppet før.

Risici, denne foranstaltning håndterer

Fra det startrisikoregister, StandardOS foreslår ved opsætningen. I beholder, redigerer eller sletter hver enkelt; dette er dem, der nævner A.8.29 som håndtering.

• Kode skrevet af en leverandør når produktion uden gennemgangApplikation

Hvad kunder spørger om ved denne foranstaltning

Sikkerhedsspørgeskemaer bruger ikke foranstaltningsnumre. Dette er de spørgsmål, som kunder stiller dem, der lander på A.8.29. Hvert af dem besvares ud fra de samme fire registreringer: SoA-status, den godkendte politik, dateret bevis og et levende tjek. Det fulde kort over de tredive emner.

• Følger I en sikker udviklingscyklus med kodegennemgang og ændringsstyring?

  Sikker udvikling, kodegennemgang, ændringsstyring, CI/CD · også A.8.25, A.8.32

Hvor dette hører til under NIS2

A.8.29 er en del af det, artikel 21, stk. 2, litra e), Security in network and information systems acquisition, development and maintenance, kræver. At implementere det én gang tæller for begge, og det er hele grunden til, at NIS2-kortlægningen findes.