PCI Security Standards Council har släppt version 2.0 av Secure Software Standard och dess tillhörande Program Guide, vilket är den mest betydande revideringen sedan ramverket infördes 2019. Denna uppdatering omformar i grunden hur betalningsprogramvara utvärderas och valideras, introducerar ny terminologi, utökad omfattning och strömlinjeformade processer som kommer att påverka leverantörer, bedömare och kunder i hela betalningsekosystemet.

Grunden: Ett nytt synsätt på behörighet och omfattning

Den kanske mest grundläggande förändringen i v2.0 är att termen "Payment Software" helt har tagits bort från standarden. Behörighetskriterierna är nu helt inriktade på konceptet Sensitive Assets - definieratsom alla delar av programvaruprodukten vars obehöriga åtkomst, användning, modifiering eller avslöjande kan äventyra programvarans betalningsrelaterade funktioner eller data.

Denna konceptuella omformulering åtföljs av ett nytt obligatoriskt dokument, Sensitive Asset Identification (SAID), som ger detaljerade sammanhang och exempel för att identifiera känsliga data, funktioner, resurser och driftsätt. För EMVCo 3DS-relaterad data hänvisar standarden nu till PCI 3DS Data Matrix-dokumentet.

Den praktiska innebörden är tydlig: om din programvara hanterar känsliga tillgångar enligt standardens definition omfattas den av standarden - oavsett om den passar in i de traditionella kategorierna för betalningsprogramvara eller inte.

Översyn av terminologin: Förstå det nya språket

Version 2.0 innehåller betydande terminologiuppdateringar som bedömare och leverantörer måste ta till sig:

Dessutom har ordlistan flyttats från ett externt SSF-dokument till Bilaga A i själva standarden, och definierade termer är nu markerade i säkerhetskraven så att de är lätta att känna igen. En ny term, "Strong Authentication", har införts, och standarden bygger nu på "Strong Cryptography" snarare än på specifika parametrar för effektiv nyckelstyrka.

Strukturell omorganisation: Kärnkrav och moduler

Standarden v2.0 har helt omstrukturerats kring elva säkerhetsmål i avsnittet Core, som gäller för all programvara som utvärderas enligt ramverket:

1. Software Architecture, Composition, and Versioning - Inklusive nya krav för Bill of Materials (BOM) och wildcard versioning
2. Sensitive Asset Identification - lägger grunden för efterföljande krav
3. Lagring och bevarande av känsliga tillgångar
4. Sensitive Modes of Operation - Formaliserad kontext för åtkomstkontroll och stark autentisering
5. Skydd avkänsliga tillgångar - Inklusive formaliserad upptäckt av avvikande beteende
6. Utdata frånkänsliga tillgångar - Med formaliserade krav på säker kanal
7. Slumptal - Förfinade krav för extern användning av RNG eller intern implementering
8. Nyckelhantering
9. Kryptografi - Ett enda övergripande krav för områden som inte täcks på annat håll
10. Hot och sårbarheter
11. Säker distribution och hantering - Inklusive krav på riktlinjer för implementering

Modulens utveckling: Vad har ändrats?

Modul A - Skydd av kontouppgifter

Kraven har reviderats för att enbart fokusera på PAN och SAD i förhållande till PCI DSS, med ytterligare sammanhang i SAID-dokumentet.

Modul B - Programvara för POI-enheter

Denna modul har bytt namn från "Terminal Software Requirements" och har effektiviserats avsevärt. Många krav (B1.1, B1.2, B1.3, B3.x, B5.x) har införlivats i kärnkraven, och SRED-kraven har reviderats.

Modul C - Programvara som är tillgänglig för allmänheten

Byter namn från "Krav på webbprogramvara" för att bättre fånga dess avsikt. Förtydligandet av omfattningen är viktigt: denna modul behandlar programvara som är tillgänglig via offentliga nätverk där i princip alla med nätverksåtkomst kan interagera med programvaran. Viktigt är att programvara som är inte allmänt tillgänglig fortfarande kan bedömas enligt denna modul efter leverantörens gottfinnande, eftersom kraven bidrar till att minska risken för all implementering.

Modul D - Programvaruutvecklingssatser (NEW)

Denna helt nya modul möjliggör bedömning av SDK:er, inklusive EMVCo 3DS SDK:er. Standarden anger uttryckligen att v2.0 så småningom kommer att ersätta den separata PCI 3DS SDK-standarden, vilket ger leverantörerna större flexibilitet genom den mer objektiva karaktären hos Secure Software Standard.

Delta-förändringar: Det nya nivåsystemet

De tidigare ändringskategorierna "Low Impact" och "High Impact" har ersatts med en Tier 1 och Tier 2 Delta Change struktur:

Nivå 1 Delta-ändringar

• Icke-säkerhetspåverkande ändringar där versionsnummer måste ändras men jokertecken inte används
• SSLC-kvalificerade leverantörers fördel: Säkerhetspåverkande buggfixar/patchar, även när det gäller känsliga tillgångar, kvalificeras som Tier 1 och kan lämnas in utan inblandning av bedömare

Nivå 2 Delta-förändringar

• Introduktion av nya typer av känsliga tillgångar
• Förändringar som kräver bedömning av krav som tidigare inte bedömts
• Förändringar som involverar eller påverkar känsliga tillgångar (utom Tier 1-berättigade förändringar för SSLC-leverantörer)
• Ändringar av PTS POI-enhet
• Modifiering av nödvändiga beroenden
• Borttagning av specifika versioner från förteckningar

Wildcards: Formaliserat och återinfört

Versionering av jokertecken har formellt återinförts med tydliga regler:

• Definition: Ett tecken som kan ersättas av en definierad delmängd av möjliga tecken i ett versionshanteringssystem för att ta hänsyn till ändringar som inte påverkar säkerheten
• Jokertecken får endast förekomma i den högra (minst signifikanta) delen av versionsnumren
• Tillåtna jokertecken: gemener {x, y, z}, versaler {X, Y, Z} eller asterisk (*)
• Ett enda jokertecken representerar en enda siffra som ersätter {0-9}
• Jokertecken kan inte representera säkerhetspåverkande ändringar

Denna formalisering gör det möjligt för leverantörer att hantera mindre utgåvor utan att skicka in ändringar till PCI SSC, förutsatt att användningen av jokertecken valideras under den fullständiga bedömningen.

Krav för utvärdering: Källkod är obligatoriskt

Version 2.0 gör explicit vad som tidigare var implicit: källkodsbestämmelser är obligatoriska. Programguiden anger otvetydigt följande:

"Programvaruleverantören förväntas tillhandahålla källkoden för den programvaruprodukt som utvärderas, om den utvärderare som utför utvärderingen anser det nödvändigt. Det är inte möjligt att få en programvaruprodukt bedömd enligt denna standard utan att tillhandahålla relevant källkod."

Testkraven har skrivits om helt och hållet kring tre metoder:

1. Granskning av dokumentation
2. Statisk analys
3. Dynamisk analys

Livscykel och administrativa processer

Den 3-åriga livscykeln för validering förblir intakt:

• År 1 och 2: Årligt intygande från leverantören krävs
• År 3: Ny bedömning krävs för att behålla listningen

Viktiga förtydliganden i v2.0:

• Administrativ upphörandeperiod: 45 kalenderdagar efter missad tidsfrist för attestering, visas i orange på listningar
• Listning upphör att gälla: Efter den 45 dagar långa respitperioden blir produkterna utgångna Secure Software Products
• Utgångna produkter kräver ny bedömning, inte omprövning, för att listningen ska återinföras

Meddelande om säkerhetsproblem: Nytt särskilt avsnitt

Version 2.0 introducerar ett särskilt avsnitt 8 för anmälan av säkerhetsproblem, som formaliserar:

• Tidskrav för avisering enligt VRA
• Obligatoriskt meddelandeformat (skriftligt, föregås av e-post)
• Minimikrav på information om anmälan, inklusive CVSS-poängsättning
• PCI SSC:s svarsåtgärder inklusive potentiell återkallelse av godkännande

Praktiska konsekvenser för intressenter

För programvaruleverantörer

• Granska dina produkter mot den nya definitionen av känslig tillgång
• Uppdatera versionshanteringsmetoderna för att utnyttja fördelarna med wildcard
• Förbered omfattande BOM:er för bedömning
• Överväg SSLC-kvalificering för Tier 1 Delta Change-fördelar
• Säkerställ att källkoden är tillgänglig för utvärderingar

För SSF-bedömningsföretag

• Genomgå erforderlig v2.x-utbildning innan du utför utvärderingar
• Bekanta dig med det nya SAID-dokumentet
• Uppdatera utvärderingsmetoderna för den nya strukturen för testkrav
• Förbereda för SDK-bedömningar enligt modul D

För kunder

• Kontrollera att leverantörerna tillhandahåller implementeringsvägledning som överensstämmer med listade versionsnummer
• Förstå att Required Dependencies är en del av valideringen - användning av icke-listade beroenden ogiltigförklarar listningen
• Övervaka leverantörens intygsdatum och tidslinjer för omprövning

Slutsats

PCI Secure Software Standard v2.0 representerar en mognad av ramverket, som går från föreskrivande kategorier för betalningsprogramvara till ett principbaserat tillvägagångssätt som är inriktat på skydd av känsliga tillgångar. Införandet av SDK-utvärderingsfunktioner, formaliserad versionering med jokertecken och det differentierade deltaändringssystemet pekar alla mot ett mer flexibelt och hållbart valideringsprogram.

För organisationer som för närvarande har v1.x-valideringar eller planerar nya bedömningar är det nu dags att samarbeta med kvalificerade SSF Assessor Companies för att förstå övergångsvägen och utnyttja den förbättrade flexibiliteten som denna stora revision ger.

PCI Secure Software Standard v2.0 och Program Guide v2.0 gäller från och med januari 2026. Organisationer bör konsultera den officiella PCI SSC-dokumentationen och kvalificerade bedömare för specifik vägledning om efterlevnad.