Säker utvecklingslivscykel - Mönster
Lär dig mer om Well-Architected Trust → Säker utvecklingslivscykel
Säkerhet måste integreras genom hela utvecklingslivscykeln, från inledande design till distribuering och drift. Dessa mönster aktiverar säkerhetsrutiner för skift-vänster, hanterar vanliga sårbarheter och säkrar dina pipelines för distribution.
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Utveckling | Tooling | ✅ IDE säkerhetsskanning integrerad i utvecklarens arbetsflöde |
| Utveckling | Design | ✅ Hotmodellering slutförd under designfasen med STRIDE-metodik |
| Utveckling | Krav | ✅ Säkerhetskrav inkluderade i användarberättelser och acceptanskriterier |
| Utveckling | Källkontroll | ✅ Förbindelsekrokar upprätthåller säkerhetspolicyer (hemlig skanning, kodanalys) |
| Utveckling | Utbildning | ✅ Developer säkerhetsutbildning uppdateras regelbundet för att återspegla växande hot |
| Utveckling | CI/CD | ✅ Automatiserade säkerhetstester i CI / CD-pipeline misslyckas bygger på viktiga upptäckter |
| Utveckling | Kodgranskning | ✅ Säkerhet peer reviews som krävs för autentisering, auktorisering och dataåtkomstkod |
| Utveckling | Kodanalys | ✅ Säker kodning standarder som upprätthålls genom linters och statisk analys |
| Utveckling | Beroenden | ✅ Skanna beroende sårbarhet körs på varje begåvning |
| Utveckling | Tester | ✅ Penetrationstestomfattning inkluderar nya funktioner innan GA-utgåva |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Utveckling | Tester | ⚠️ Säkerhetstest uppskjuten till manuell granskning innan utgivning |
| Utveckling | Utbildning | ⚠️ Säkerhetsutbildning som endast genomförs en gång under introduktion |
| Utveckling | Kodgranskning | ⚠️ Säkerhetsteam granskar kod efter koppling |
| Utveckling | Design | ⚠️ Hotmodeller uppdateras inte när arkitekturen ändras |
| Utveckling | Källkontroll | ⚠️ Hemlig skanning inaktiverad för att minska falska positiva resultat |
| Utveckling | CI/CD | ⚠️ Säkerhetsbrister ignoreras när releasedatum närmar sig |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Injektion | ✅ SOQL-frågor använder bundna variabler för att förhindra injektion |
| Injektion | ✅ Användarinmatning validerad och desinficerad innan användning i SOQL, SOSL eller dynamiska sökfrågor |
| Injektion | ✅ Dynamisk SOQL begränsad till endast betrodda inmatningar |
| Åtkomstkontroll | ✅ CRUD och FLS-behörigheter tillämpade med Security.stripInaccessible() |
| XSS | ✅ Lightning komponenter undgår användarskapat innehåll i UI rendering |
| Injektion | ✅ Externa API-integreringar validerar och rengör alla inmatningar |
| Åtkomstkontroll | ✅ Gästanvändaråtkomst minimerad och kraftigt begränsad |
| Autentisering | ✅ autentiseringsuppgifter som används för extern autentisering (inte hårdkodade inloggningsuppgifter) |
| Autentisering | ✅ OAuth 2.0-flöden implementerade korrekt med PKCE |
| Sessionshantering | ✅ Sessionsäkerhetspolicyer tillämpar timeout och IP-begränsningar |
| Konfiguration | ✅ Säkerhetshälsokontroll granskas kvartalsvis och högriskresultat åtgärdas |
| Åtkomstkontroll | ✅ Egna metadata och behörigheter granskade för att förhindra överprivilegiering |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Injektion | ⚠️ SOQL-frågor konstruerade med strängsammanslagning med användarinmatning |
| Åtkomstkontroll | ⚠️ Gästanvändarprofiler beviljade behörigheterna Skapa, Uppdatera eller Ta bort |
| XSS | ⚠️ Lightning använder ej dolda uttryck i mallar |
| Autentisering | ⚠️ Externa integreringar använder hårdkodade inloggningsuppgifter i kod |
| Loggning | ⚠️ Felsökningsloggar innehåller känsliga data som lösenord eller PII |
| Åtkomstkontroll | ⚠️ FLS- och CRUD-kontroller utelämnas eftersom “vi kontrollerar alla användare” |
| Konfiguration | ️ Hälsokontrollresultat ignoreras eller skjuts upp på obestämd tid |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Pipeline | Källkontroll | ✅ Grenskyddsregler tillämpar obligatoriska granskningar och statuskontroller |
| Pipeline | Åtkomstkontroll | ✅ Distribution pipelines använder servicekonton med minimala behörigheter som krävs |
| Pipeline | Hemligheter | ✅ hemligheter som lagras i säkra valv (aldrig i källkontroll eller miljövariabler) |
| Pipeline | Distribuering | ✅ Produktionsdistribueringar kräver manuellt godkännande grind från auktoriserad personal |
| Pipeline | Granska | ✅ Distributionsloggar samlar in vem som distribuerade vad när med godkännandespår |
| Pipeline | Validering | ✅ Validering före distribution inkluderar säkerhetsskanningar och efterlevnadskontroller |
| Pipeline | Åtkomstkontroll | ✅ Flerfaktorsautentisering krävs för pipeline administrativ åtkomst |
| Pipeline | Bevakning | ✅ Pipelinekonfigurationsändringar utlöser säkerhetsteamnotiser |
| Pipeline | Validering | ✅ Automatiserad validering efter distribution bekräftar förväntade säkerhetskontroller aktiva |
| Pipeline | Beroenden | ✅ Beroendeuppdateringar utvärderade för säkerhetspåverkan innan distribuering |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Pipeline | Hemligheter | ⚠️ Hemligheter som är förpliktade till versionskontroll (även om de senare tas bort) |
| Pipeline | Källkontroll | ⚠️ Vem som helst kan koppla till huvud-/produktionsgren utan granskning |
| Pipeline | Åtkomstkontroll | ⚠️ Distributionspipeline körs med behörigheter på administratörsnivå |
| Pipeline | Distribuering | ⚠️ Produktionsdistribueringar helt automatiserade utan godkännandegrindar |
| Pipeline | Granska | ⚠️ Distributionsloggar samlar inte in vem som initierade eller godkände ändringar |
| Pipeline | Validering | ⚠️ Misslyckade säkerhetsskanningar ignoreras eller förbigås för att uppfylla deadlines |
| Pipeline | Bevakning | ⚠️ Ändringar av pipelinekonfiguration spåras eller granskas inte |
| Pipeline | Validering | ⚠️ Validering efter distribution kontrollerar endast att funktionen är korrekt |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Tester | Statisk analys | ✅ Salesforce Code Analyzer körs i Developer IDEs för omedelbar feedback och i CI / CD-pipeline som automatiserade grindar |
| Tester | Penetrationstest | ✅ Penetrationstester utförda för egna program exponerade för opålitliga användare, särskilt Experience Cloud-webbplatser och offentliga API:n |
| Tester | Enhetstester | ✅ Säkerhetsfokuserade Apex enhetstester körs som användare med olika behörighetsprofiler |
| Testa | Beroenden | ✅ Beroendeskanning övervakar AgentExchange-paket och JavaScript-bibliotek för kända sårbarheter |
| Tester | Säkerhetsgranskning | ✅ Statisk analysrapport förberedd för varje AppExchange eller AgentExchange säkerhetsgranskning |
| Tester | Säkerhetsgranskning | ✅ Dynamisk skanning (penetrationstest) rapport förberedd när en lösning integrerar en webbapplikation eller tjänst från tredje part |
| Testa | Beroenden | ✅ Säkerhetsråd för installerade paket prenumererade på och övervakade |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Tester | Täckning | ⚠️ Säkerhetstest förlitar sig på en enskild teknik, t.ex. endast statisk analys |
| Tester | Enhetstester | ⚠️ Apex test validerar funktionellt beteende men körs aldrig som användare med lägre behörighet |
| Tester | Säkerhetsgranskning | ️ AppExchange eller AgentExchange-inskickning förberedd utan den statiska analys eller dynamiska skanningsrapporter som krävs |
| Tester | Penetrationstest | ⚠️ Penetreringstest hoppas över för Experience Cloud-webbplatser och API:n som visas offentligt |
Se även:
- Efterlevnads- och regleringsmönster – Plattformsstyrning och granskningskontroller
- Mönster för identitets- och åtkomsthantering — Autentisering och auktorisering
- Incidentsvarsmönster — Upptäckt och svar på säkerhetshändelser
- Agentiska mönster — Agentspecifika säkerhetskontroller