Sikker udviklingslivscyklus - mønstre
Læs mere om Well-Architected Trust → Secure Development Lifecycle
Sikkerhed skal integreres gennem udviklingslivscyklussen fra det indledende design til implementering og drift. Disse mønstre aktiverer sikkerhedspraksisser, der skifter til venstre, håndterer almindelige sårbarheder og sikrer dine implementeringspipelines.
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Udvikling | Tooling | ✅ IDE-sikkerhedsscanning integreret i udviklerarbejdsflow |
| Udvikling | Design | ✅ Trusselmodellering udført under designfase ved brug af STRIDE-metodologi |
| Udvikling | Krav | ✅ Sikkerhedskrav, der er inkluderet i brugerhistorier og acceptkriterier |
| Udvikling | Kildekontrol | ✅ Før bekræftelse-hakker håndhæver sikkerhedspolitikker (hemmelig scanning, kodeanalyse) |
| Udvikling | Uddannelse | ✅ Udviklersikkerhedsuddannelse opdateres regelmæssigt for at afspejle udviklende trusler |
| Udvikling | CI/CD | ✅ Automatiseret sikkerhedstest i CI/CD-pipeline mislykkes bygger på vigtige resultater |
| Udvikling | Kodegennemgang | ✅ Peer-reviews for sikkerhed kræves for godkendelse, autorisation og datadgangskode |
| Udvikling | Kodeanalyse | ✅ Sikker kodningsstandarder håndhævet gennem linters og statiske analyser |
| Udvikling | Afhængigheder | ✅ Afhængighedssårbarhedsscanning køres på hver bekræftelse |
| Udvikling | Test | ✅ Omfanget af penetrationstest inkluderer nye funktioner før GA-frigivelse |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Udvikling | Test | ⚡️ Sikkerhedstest udskudt til manuel gennemgang før frigivelse |
| Udvikling | Uddannelse | ⚡️ Sikkerhedsundervisning udført kun en gang under introduktion |
| Udvikling | Kodegennemgang | ⚡️ Sikkerhedsteam gennemser kode efter fletning |
| Udvikling | Design | ⚡️ Trusselmodeller opdateres ikke, når arkitekturen ændres |
| Udvikling | Kildekontrol | ⚡️ Hemmelig scanning inaktiveret for at reducere falske positive |
| Udvikling | CI/CD | ⚡️ Sikkerhedsresultater ignoreret, når frigivelsesdeadlines forekommer |
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Injektion | ✅ SOQL-forespørgsler bruger bindingsvariabler til at forhindre injektion |
| Injektion | ✅ Brugerinput valideret og saniteret før brug i SOQL-, SOSL- eller dynamiske forespørgsler |
| Injektion | ✅ Dynamisk SOQL er kun begrænset til betroede input |
| Adgangskontrol | ✅ CRUD- og FLS-tilladelser håndhævet ved brug af Security.stripInaccessible() |
| XSS | ✅ Lightning escape brugergenereret indhold i gengivelse af brugergrænseflade |
| Injektion | ✅ Eksterne API-integrationer validerer og sanererer alle input |
| Adgangskontrol | ✅ Gæstebrugeradgang minimeret og kraftigt begrænset |
| Godkendelse | ✅ Navngivne legitimationsoplysninger, der bruges til ekstern godkendelse (ikke hardcodede legitimationsoplysninger) |
| Godkendelse | ✅ OAuth 2.0-forløb implementeret korrekt med PKCE |
| Sessionsstyring | ✅ Sessionssikkerhedspolitikker håndhæver timeout- og IP-begrænsninger |
| Konfiguration | ✅ Sikkerhedstilstandscheck gennemset kvartalsvis og resultater med høj risiko rettet |
| Adgangskontrol | ✅ Tilpassede metadata og tilladelser revideret for at forhindre overbevisning |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Injektion | ⚡️ SOQL-forespørgsler, der er opbygget ved brug af strengsamkædning med brugerinput |
| Adgangskontrol | ⚡️ Gæstebrugerprofiler tildelt tilladelserne Opret, Opdater eller Slet |
| XSS | ⚡️ Lightning bruger ikke-escaped-udtryk i skabeloner |
| Godkendelse | ⚡️ Eksterne integrationer bruger hardcodede legitimationsoplysninger i kode |
| Logføring | ⚡️ Fejlretningslogfiler indeholder følsomme data som adgangskoder eller personligt identificerbare oplysninger |
| Adgangskontrol | ⚡️ FLS- og CRUD-kontroller udeladt, fordi “vi kontrollerer alle brugerne” |
| Konfiguration | Resultater fra Sikkerhedstilstandscheck ignoreret eller udskudt for ubestemt tid |
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Pipeline | Kildekontrol | ✅ Forgreningsbeskyttelsesregler håndhæver påkrævede gennemgange og statuskontroller |
| Pipeline | Adgangskontrol | ✅ Implementerings-pipelines bruger servicekonti med minimale krævede tilladelser |
| Pipeline | Hemmeligheder | ✅ Hemmeligheder, der er lagret i sikre værdiboks (aldrig i kildekontrol eller miljøvariabler) |
| Pipeline | Implementering | ✅ Produktionsimplementeringer kræver manuel godkendelsesgate fra autoriseret personale |
| Pipeline | Revision | ✅ Implementeringslogfiler registrerer, hvem der implementerede hvad og hvornår med godkendelsesspor |
| Pipeline | Validering | ✅ Validering før implementering inkluderer sikkerhedsscanninger og overensstemmelseskontroller |
| Pipeline | Adgangskontrol | ✅ Godkendelse med flere faktorer kræves for administrativ pipelineadgang |
| Pipeline | Overvågning | ✅ Ændringer af pipelinekonfiguration udløser adviseringer om sikkerhedsteam |
| Pipeline | Validering | ✅ Automatiseret validering efter implementering bekræfter, at de forventede sikkerhedskontroller er aktive |
| Pipeline | Afhængigheder | ✅ Afhængighedsopdateringer evalueret for sikkerhedspåvirkning før implementering |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Pipeline | Hemmeligheder | ⚡️ Hemmeligheder, der er bekræftet til versionskontrol (selv hvis de senere fjernes) |
| Pipeline | Kildekontrol | ⚡️ Enhver kan flette til hoved-/produktionsforgrening uden gennemgang |
| Pipeline | Adgangskontrol | ⚡️ Implementerings-pipelines kører med tilladelser på administratorniveau |
| Pipeline | Implementering | ⚡️ Produktionsimplementeringer fuldt automatiseret uden godkendelsesgate |
| Pipeline | Revision | ⚡️ Implementeringslogfiler registrerer ikke, hvem der startede eller godkendte ændringer |
| Pipeline | Validering | ⚡️ Mislykkede sikkerhedsscanninger ignoreret eller tilsidesat for at opfylde deadlines |
| Pipeline | Overvågning | ⚡️ Pipelinekonfiguration ændres ikke sporet eller gennemset |
| Pipeline | Validering | ⚡️ Validering efter implementering kontrollerer kun funktionel korrekthed |
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Test | Statisk analyse | ✅ Salesforce Code Analyzer kører i udvikler-id’er for øjeblikkelig feedback og i CI/CD-pipelines som automatiserede porte |
| Test | Penetrationstest | ✅ Penetrationstest udført for tilpassede applikationer, der vises for brugere, der ikke har tillid til, især Experience Cloud-lokaliteter og offentlige API’er |
| Test | Enhedstest | ✅ Sikkerhedsfokuserede Apex kører som brugere med forskellige tilladelsesprofiler |
| Test | Afhængigheder | ✅ Afhængighedsscanning overvåger AgentExchange-pakker og JavaScript-biblioteker for kendte sårbarheder |
| Test | Sikkerhedsgennemgang | ✅ Statisk analyserapport udarbejdet for hver indsendelse af AppExchange eller AgentExchange-sikkerhedsgennemgang |
| Test | Sikkerhedsgennemgang | ✅ Dynamisk scanningsrapport (penetrationstest), der er forberedt, når en løsning integrerer en tredjepartsapplikation eller tjeneste |
| Test | Afhængigheder | ✅ Sikkerhedsadviseringer for installerede pakker, der abonneres på og overvåges |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Test | Dækning | ⚡️ Sikkerhedstest er baseret på en enkelt teknik, f.eks. statisk analyse alene |
| Test | Enhedstest | Apex validerer funktionel adfærd, men kører aldrig som brugere med lavere rettigheder |
| Test | Sikkerhedsgennemgang | ⚡️ AppExchange eller AgentExchange indsendelse udarbejdet uden de krævede statiske analyser eller dynamiske scanningsrapporter |
| Test | Penetrationstest | ⚡️ Overførselstest ignoreret for offentlige Experience Cloud-lokaliteter og API’er |
Se også:
- Compliance and Regulatory Patterns – Platformsstyring og revisionskontrol
- Identitets- og adgangsstyringsmønstre – Godkendelse og autorisation
- Hændelsessvarmønstre – sikkerhedsbegivenhedsregistrering og -svar
- Agentmønstre – agentspecifikke sikkerhedskontroller