Indhentningen af krav sker i samarbejde med kunden, hvor formålet er at identificere hvilken forretningsmæssig værdi projektet skal skabe, så krav og funktioner kan prioriteres derefter. Typisk anvendes user stories og workshops til at sikre en effektiv dialog om krav og behov mellem kunden og udviklingsteamet. Denne proces bidrager samtidig til at sikre, at softwareløsningen understøtter både forretningsmål og tekniske krav.

Efter man har kortlagt kundens krav, skal kravene i denne fase omdannes til praktiske opgaver der kan implementeres i projektet. En måde at gøre omfattende kundekrav mere håndgribelige er ved at dele opgaverne op i mindre delopgaver. Typisk vil udviklerne lave visuelle præsentationer af deres løsninger for at give kunden bedre indblik i udviklingsteamets ideer; her bruges ofte wireframes og prototyper for at få yderligere feedback til projektet og til systemets design.

Som en del af lovgivningen indføres der en forpligtelse til at yde løbende support gennem hele livscyklussen for de omfattede produkter, herunder håndtering af sikkerhedsopdateringer og sårbarheder.

Test af kode er en vigtig del af hver iteration, der går ud på at sikre kvalitet, funktionalitet og stabilitet af softwaren. Man bruger typisk unit-tests til at verificere, at de individuelle komponenter af systemet arbejder sammen efter hensigt. Herefter laver udviklingsteamet slutbruger-tests, hvor brugere får lov at interagere med softwaren, så man er sikker på at imødekomme kundens krav til produktet og sikre den ønskede funktionalitet.

Udgivelse af kode går i høj grad ud på at levere funktionalitet til produktet. Hertil benyttes der typisk automatiserede værktøjer og CI/CD-processer, der tillader hurtige og ensartede udgivelser af software. Det er vigtigt at overvåge udgivelsesprocessen, da det giver mulighed for at fejl kan identificeres og rettes hurtigt.

Feedback er et essentielt step i forbedringen af produktet og i den løbende videreudvikling af softwareløsningen. Kunder og slutbrugere kan sende deres feedback gennem enten et spørgeskema, direkte kommunikation eller analyse af produktets brug. Denne feedback bruges til at finpudse krav, identificere mangler og prioritere ændringer i fremtidige iterationer af systemet.

Organisationer skal identificere og registrere informationsaktiver. Softwarekomponenter og afhængigheder kan betragtes som digitale aktiver, hvor en SBOM kan fungere som en detaljeret registrering og dokumentation af softwareaktiver i organisationens systemer.

ISO 27001 stiller krav til sikkerhed i udviklingsprocesser. Her kan SBOM med fordel integreres i Secure Software Development Lifecycle (SSDLC). Dette kan f.eks. ske gennem automatiseret generering af SBOM i CI/CD-pipelines som dokumentation for softwarekomponenter i et system.

En automatiseret SBOM i CI/CD-processer kan mindske tidsforbruget og samtidig understøtte scanning af de komponenter der tilføjes, herunder open source komponenter, så organisationen får et bedre overblik over softwarekomponenternes afhængigheder.

SEn SBOM understøtter sårbarhedshåndtering fordi den kan bruges til at identificere hvilke systemer der er påvirket af kendte sårbarheder. Dette gør det muligt at prioritere patching og sikkerhedsopdateringer baseret på eksponeringen af softwarekomponenter.

I et ISO 27001-baseret ISMS kan SBOM integreres i flere centrale processer, blandt andet forvaltning af aktiver, risikostyring, leverandørkædesikkerhed og sårbarhedshåndtering. SBOM fungerer dermed som et værktøj til at gøre flere af standardens kontroller mere operationelle og praktisk anvendelige i organisationens cybersikkerhedsarbejde.