TL; DR
De fleste sikkerhetskrav for programvareutvikling er skrevet som intensjoner, noe som betyr at ingen kan bestå eller stryke på dem. «Avhengigheter må være sikre» er lett å lese og overlever gjennomgang, helt frem til det øyeblikket en revisor ber om å se filen. Denne sjekklisten for programvaresikkerhetskrav gir deg 12 linjer skrevet omvendt.
- Et krav er bare verifiserbart når tre ting er til stede. En navngitt artefakt, et øyeblikk den blir kontrollert, og en definert oppførsel når kontrollen mislykkes. De fleste sikkerhetskrav for programvare mislykkes på det første tidspunktet.
- Hver av de 12 linjene produserer bevis. En proveniensbekreftelse, en SBOM knyttet til en utgitt versjon, et tidsstempel for tilbakekalling, en gate decision med en eier. Ikke en skannerrapport.
- De delte seg inn i tre grupper. Hva kommer inn i programvaren din, hva bygger den, og hva beviser dens tilstand.
- Å bekrefte dem er en SSCS og ASPM problem, ikke et skannerproblem. Seks verktøy produserer seks dashboards, og en revisor ønsker ett svar. Bevisene må komme fra ett sted, ellers kommer de ikke i det hele tatt.
Hvorfor feiler de fleste sikkerhetskrav for programvareutvikling i det øyeblikket noen reviderer dem?
Åpne nesten alle dokumenter med sikkerhetskrav, og du vil finne setninger som «tredjepartskomponenter må være fri for kjente sårbarheter» og «bygget». pipeline må sikres». De leses godt. De overlever gjennomgang. Og så en revisor, et sikkerhetsspørreskjema for kunder, eller en 2 NOK or DORA Assessor stiller et enkelt spørsmål: vis meg.
På det tidspunktet faller kravet sammen, fordi ingen skrev ned hva «fri for kjente sårbarheter» betyr på hvilket punkt i livssyklusen, hvem som bestemmer og hvilken fil du overleverer. Teamet jobber seg frem, eksporterer en skannerrapport og håper at mengden funn leses som due diligence.
Gapet er ikke innsats. Team som kjører fire eller fem verktøy gjør mye arbeid. Gapet er at kravene til programvaresikkerhet ble skrevet for å beskrive en ønsket tilstand i stedet for en kontrollerbar hendelse. En ønsket tilstand har ingen bevis knyttet til seg. Det har en hendelse. Alt som gjør programvareutviklingssikkerhet reviderbar kommer fra dette skillet.
Hva gjør et sikkerhetskrav for programvare verifiserbart?
Tre egenskaper, og et krav krever alle tre:
- En navngitt artefakt. En attest, en SBOM, en signert plate, en gate decision. Noe som finnes som en fil eller en loggoppføring og kan fremvises på forespørsel.
- Et øyeblikk. Pull request, bygge, utgi eller kontinuerlig. «På et tidspunkt i SDLC«er ikke et øyeblikk.»
- En definert feilatferd. Hva skjer når sjekken mislykkes: blokker, advarsel, karantene eller rute til en navngitt eier med en dokumentert unntakssti.
Kjør dine nåværende krav gjennom disse tre egenskapene. De fleste av dem vil mislykkes på den første, og det er derfor teamene ender opp med å forhandle med revisorer i stedet for å svare på dem.
De 12 linjene nedenfor er skrevet slik at hver av dem består alle tre. De er bevisst kjedelige. Verifiserbare krav er vanligvis det.
Sjekkliste for sikkerhetskrav for programvareutvikling: 12 linjer som faktisk kan verifiseres
Hver linje navngir gjenstanden som beviser den, spørsmålet som tester den, og hvor beviset kommer fra.
Gruppe én: hva som kommer inn i programvaren din
| Krav | Bekreft av | bevis |
|---|---|---|
| 01Hver avhengighet blir screenet for ondsinnet oppførsel uten å vente på en publisert signatur | Be om vurderingen av screeningen for alle pakker som er lagt til i løpet av de siste 30 dagene | Tidlig advarsel om skadelig programvare oppdager ondsinnede pakker på tvers av kode, pipelines, IaC og registre før en signatur eller rådgivning finnes, ved bruk av bevisdeteksjon etterfulgt av AI-validering |
| 02Hver utgivelse har en SBOM, kan hentes frem etter versjon, generert av byggingen i stedet for å settes sammen for hånd | Navngi en utgitt versjon og be om dens navn SBOM innen fem minutter | SBOM generasjon per bygg, med vedlagt rapportering om sårbarhetsopplysninger |
| 03En sårbarhet blokkerer bare en utgivelse når den er tilgjengelig i koden din. | Tar tre blokkerte funn og spør hvilken funksjonssti som gjør dem utnyttbare | Tilgjengelighet på funksjonsnivå, utnyttbarhet og EPSS i prioriteringstrakten |
| 04Kjente sårbare komponenter har en eier og en decision, ikke bare en billett | Å velge ut et hvilket som helst åpent kritisk funn og spørre hvem som aksepterte risikoen, og frem til når | Eierskap og status spores mot aktivumet, ikke mot en skanning |
| 05Avhengigheter mellom kunstig intelligens og maskinlæring behandles som en vanlig forsyningskjede, fordi de er | Spørsmål om hvilke CVE-er som påvirker ML-bibliotekene i produksjon i dag | Sammensetningsanalyse som dekker AI-stakken på samme plattform som AI-ressursene som bruker den |
Gruppe to: hva som bygger programvaren din
| Krav | Bekreft av | bevis |
|---|---|---|
| 06Hvert bygg produserer en proveniensbekreftelse som kan verifiseres uavhengig | Hente ut attestasjonen for den nyeste produksjonsartefakten og sjekke den mot kilden commit | SLSA provenance og tilpassede in-toto-attestasjoner med nøkkelfrie signaturer, lagret i et hvilket som helst register, med manipulerte gjenstander blokkert før levering |
| 07Pipeline konfigurasjonen skannes som kode, i samme kadens som applikasjonskoden | Spørsmål om når den siste endringen i GitHub Actions- eller Jenkins-konfigurasjonen ble sikkerhetsgjennomgått, og av hva | CI/CD sikkerhet dekker pipeline feilkonfigurasjon, forgiftede arbeidsflyter og risiko i forsyningskjeden, med SSCS innebygd samsvar |
| 08Enhver hemmelighet som finnes hvor som helst i livssyklusen blir tilbakekalt, ikke bare rapportert | Ber om de fem siste oppdagede hemmelighetene og tidsstemplene for tilbakekalling | Deteksjon på tvers av kode, konfigurasjoner, containere og pipelinemed over 100 hemmelige typer, pluss automatisk tilbakekallelse playbooks per legitimasjonstype |
| 09Unormal aktivitet i pipeline utløser et varsel før det blir en hendelse | Spør hva en kompromittert løper eller en uvanlig commit mønsteret ville utløse, og hvem som mottar det | Anomali påvisning på aktivitet som går forut for et angrep |
Gruppe tre: hva beviser tilstanden til programvaren din
| Krav | Bekreft av | bevis |
|---|---|---|
| 10Infrastruktur ettersom koden er portert før sammenslåing, ikke korrigert etter utrulling | Spør om en usikker Terraform-endring kan nå main, og hva som stopper den | IaC skanning med guardrails på pull request |
| 11Funn fra alle verktøy, både ditt og tredjeparts, deler én alvorlighetsmodell | Spørre om en kritisk melding fra én skanner og en kritisk melding fra en annen betyr det samme for teamet ditt | Ocuco ASPM lag inntar funn fra SAST, SCA, DAST og IaC verktøy du allerede kjører, hvem som helst som har bygget dem, og bruker samme prioritering, sortering, forklaring og utbedring som det gjør på native funn |
| 12Alle AI-ressurser i kodebasen er inventarisert og kan eksporteres | Spørre hvilke modeller, agenter og MCP-servere som kjører i applikasjonene dine, og be om filen | Kontinuerlig oppdagelse av modeller, rammeverk, datasett, inferensendepunkter, agenter, MCP-servere, ferdigheter, ledetekster og AI-kodingsverktøy, med en CycloneDX ML-BOM generert på hver skanning |
Hvem eier hver linje i sjekklisten?
Et kravdokument uten eierkolonne er en ønskeliste. Tildel hver linje før du publiserer den:
Den andre kolonnen er den som feiler i praksis. Kontinuerlig verifisering fungerer bare når bevisene samler seg selv.
Hvordan verifiserer du en sjekkliste for sikkerhetskrav for programvareutvikling uten å legge til en ekstra konsoll?
Det er her de fleste programmene stopper opp. De 12 kravene ovenfor gjelder berøringsavhengigheter, pipelines, bygge artefakter, hemmeligheter, infrastrukturkode og AI-ressurser. Bekreft dem med seks separate verktøy, og du har laget en syvende jobb: avstemme seks dashboards til ett svar for en revisor som ønsker et enkelt tall.
To egenskaper gjør dette håndterbart.
- Software supply chain security (SSCS) dekker kravene som ligger mellom commit og gjenstanden. Avhengigheter, pipelines, byggintegritet, hemmeligheter og anomal aktivitet er én angrepsflate, og det er også der de vanskeligste å forfalske bevisene kommer fra: en signert bekreftelse er verdt mer for en taksator enn en skannerrapport, fordi den ikke kan gjenopprettes i etterkant.
- ASPM er laget som omgjør funn til en holdning du kan rapportere. Det er viktig her av en spesifikk grunn: det inntar det dine eksisterende skannere allerede produserer. Du trenger ikke å erstatte verktøyet du allerede har betalt for for å oppfylle denne sjekklisten. Resultatet blir input, og samme prioritering, AI-sortering, forklaring og utbedring gjelder for disse funnene og for native funnene. Et sikkerhetsprogram for programvareutvikling bygget på en plattform som bare forstår sine egne skannere, vil feile hver gang eiendommen blandes, og alle eiendommer blandes.
Hva endres når en agent skriver koden?
Alt ovenfor forutsatte at et menneske skrev endringen og at et annet menneske gjennomgikk den. Denne antagelsen er i ferd med å utløpe, og den omformer hva programvareutviklingssikkerhet må dekke.
Når en kodeagent produserer tusen filer i løpet av en uke, slutter kodegjennomgang å være en kontroll og blir en kø. Tre av de 12 linjene bærer mesteparten av vekten i den verdenen: screening av ondsinnede avhengigheter (fordi agenter henter pakker raskt, og hallusinerte pakkenavn nå er en registrert angrepsvektor), pull request analyse rangert etter utnyttbarhet snarere enn rå alvorlighetsgrad, og beholdning av AI-eiendeler.
Det er også et fjerde krav som er verdt å legge til i enhver sjekkliste for programvaresikkerhetskrav skrevet i 2026: Konfigurasjonsfilene som instruerer AI-verktøyet ditt, gjennomgås som sikkerhetsartefakter. Ferdighetsfiler, regelfiler og MCP-serverkonfigurasjoner er committeres som ren tekst og gjennomgås som om de var dokumentasjon, og de definerer hva en assistent er instruert til å gjøre og hva den har lov til å oppnå.
Hvordan kommer man seg fra sjekkliste til bevis?
Ikke begynn med å skrive hele dokumentet på nytt. Ta de tre linjene som din neste revisjon, kundespørreskjema eller styregjennomgang faktisk vil teste, vanligvis SBOM på forespørsel, hemmelig tilbakekallelse og byggeproveniens. Bevis disse tre ende til ende, med gjenstanden i hånden. Utvid deretter.
Sjekkliste for sikkerhetskrav for programvareutvikling er ikke et dokument som utøvescise. Det er forskjellen mellom et sikkerhetsprogram som kan svare på spørsmål og et som bare kan beskrive seg selv. Tolv verifiserbare linjer slår førti ambisiøse linjer, fordi tolv av dem overlever kontakt med noen som ber om å se filen.
Hvis sikkerhetskravene for programvaren ikke kan produsere en artefakt på forespørsel, har du ingen krav. Du har intensjoner med et versjonsnummer.
Se hva boet ditt allerede beviser. Koble til et arkiv, og Xygeni returnerer avhengighetene dine, pipelines, hemmeligheter, status for byggintegritet og AI-inventar i én enkelt holdningsvisning, med bevisene knyttet til hvert funn. Start gratis or bestill en demo.
FAQ
Hvor mange krav til programvaresikkerhet bør en sjekkliste ha?
Færre enn du tror. Det nyttige tallet er antallet du kan bekrefte på forespørsel, som for de fleste team er mellom 10 og 20. En sjekkliste med 60 krav der 45 ikke har noen bevis vedlagt, er svakere enn en sjekkliste med 12 der hver linje produserer en artefakt. Start med linjene din neste revisjon vil teste og utvid derfra.
Hva er forskjellen mellom programvareutviklingssikkerhet og et samsvarsrammeverk?
Et rammeverk som NIS2, DORA eller Cyber Resilience Act forteller deg hvilke resultater som forventes. Programvareutviklingssikkerhet er hvordan disse resultatene blir kontroller som ingeniørteamet ditt kan bestå eller ikke bestå på en gitt pull request eller bygge. Rammeverk skrives for assessorer, krav skrives for utviklere, og mesteparten av bryderiet med et samsvarsprogram kommer av at ingen gjør den oversettelsen.
Kan jeg bekrefte en sjekkliste for programvaresikkerhetskrav med skannerne jeg allerede har?
Delvis. Skannere produserer funn, og flere av disse kravene krever i stedet artefakter: en proveniensbekreftelse, en SBOM knyttet til en utgitt versjon, en tilbakekallingsoppføring, en gate decision med en eier. Det er derfor sjekklisten står på SSCS og ASPM snarere enn på en skanner. Den praktiske løsningen er å beholde de eksisterende skannerne og legge et lag over dem som inntar funnene deres og bruker én prioriteringsmodell på alle.
Hvilket krav gjør lagene oftest feil?
Hemmeligheter. Nesten alle sjekklister sier at hemmeligheter ikke må committed, og nesten ingen sier at en oppdaget hemmelighet må tilbakekalles innenfor et definert vindu. Deteksjon uten tilbakekalling etterlater en aktiv legitimasjon i et arkivs historikk, og historikken er offentlig i det øyeblikket arkivet er det. Skriv om den linjen som et tilbakekallingskrav med et tidsstempel, og den blir verifiserbar.
