💻 computer science

Specification-Driven Development Benchmark: Security Knowledge Transition

Dit artikel behandelt de beveiligingslacunes in specificatiegestuurde AI-ontwikkeling door een Multilayer Specification Security Model en een Security Knowledge Transition Method voor te stellen die beveiligingseisen operationaliseren, waarbij door middel van empirische studies wordt aangetoond dat deze benaderingen API-fouten significant verminderen in vergelijking met de baseline en ASVS-geconditioneerde generatie.

Oorspronkelijke auteurs: Oleg Grynets, Andrii Salyk, Vasyl Lyashkevych, Oleh Kaskun, Danyil Zhuravchak

Gepubliceerd 2026-06-02

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Oleg Grynets, Andrii Salyk, Vasyl Lyashkevych, Oleh Kaskun, Danyil Zhuravchak

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een supersnelle, ongelooflijk getalenteerde robotchef inhuurt om een complexe restaurantkeuken voor je te bouwen. Je geeft de robot een gedetailleerd recept (de specificatie) dat zegt: "Maak een boekingssysteem voor tennisbanen waarbij gebruikers banen kunnen boeken, kosten kunnen betalen en reserveringen kunnen annuleren."

De robot is geweldig in het volgen van het recept. Hij bouwt het fornuis, de ovens en het bestelsysteem perfect. Er is echter een probleem: je bent vergeten de robot de veiligheidsregels te geven. Je hebt niet gezegd: "Laat een klant geen baan boeken die niet van hem is," of "Zorg ervoor dat een gedeactiveerde gebruiker niet stiekem kan terugkeren," of "Laat iemand de prijs van een baan niet aanpassen nadat deze al geboekt is."

Omdat de robot niet expliciet over deze veiligheidsregels is geïnformeerd, bouwt hij een keuken die geweldig werkt voor het koken (functioneel), maar gevaarlijk is (onveilig). Het kan bijvoorbeeld iedereen de VIP-ruimte in laten lopen of een klant een andere persoon's reservering laten stelen.

Dit artikel gaat over het oplossen van dat probleem. De auteurs, een team van EPAM Systems, stellen dat wanneer we AI gebruiken om software te schrijven, we niet kunnen vertrouwen op de AI om de veiligheidsregels te "raden". We moeten ze expliciet opschrijven, net zoals we dat doen voor de kookinstructies.

Hier is de eenvoudige uiteenzetting van hun oplossing:

1. Het Probleen: De "Stille Veiligheid"-kloof

Momenteel, wanneer we AI vragen om software te bouwen, geven we het een lijst van wat de software moet doen (functionele vereisten). Maar we laten vaak weg wat de software moet voorkomen (beveiligingseisen).

De Analogie: Het is alsoals je een bewaker vertelt: "Laat mensen het gebouw binnen," maar vergeet te zeggen: "Maar laat ze niet in de kluis." De bewaker doet precies wat je zei, maar het gebouw wordt beroofd.
Het Resultaat: De AI bouwt een systeem dat perfect werkt voor de gebruiker, maar faalt in het beschermen van gegevens, het blokkeren van kwaadwillenden of het stoppen van misbruik.

2. De Oplossing: Een "Beveiligingsblauwdruk" (Het Multilayer-model)

De auteurs stellen een nieuwe manier voor om met de AI te communiceren. In plaats van alleen een recept te geven, suggereren ze het geven van een Beveiligingsblauwdruk.

Zie deze blauwdruk als een kaart die de punten verbindt tussen:

De Personages: (Wie is de gebruiker? Wie is de beheerder?)
De Schurken: (Wat zou er mis kunnen gaan? Wat als iemand probeert een boeking te stelen?)
De Regels: (Als een gebruiker probeert te stelen, moet het systeem "Nee" zeggen en hem blokkeren.)
De Test: (Hoe controleren we of het slot werkt?)

Deze blauwdruk is niet zomaar een lijst van "wees veilig". Het is een gestructureerde keten die zegt: "Omdat Gebruiker A probeert toegang te krijgen tot Bron B, en dit een risico vormt, moeten we Regel C implementeren, en zullen we dit testen met Scenario D." Dit maakt de beveiligingsregels onmogelijk voor de AI om te negeren of verkeerd te begrijpen.

3. Het Proces: Het Vertalen van de Blauwdruk

Het artikel beschrijft een methode om een normaal bedrijfsplan om te zetten in deze beveiligingsrijke blauwdruk voordat de AI begint met coderen.

Stap 1: Bekijk het bedrijfsplan.
Stap 2: Vraag de AI (of experts) om alle potentiële "schurken" en risico's te identificeren op basis van dat plan.
Stap 3: Vertaal die risico's naar specifieke, onbreekbare regels voor de code.
Stap 4: Voer dit verrijkte plan aan de AI om de software te bouwen.

4. Het Experiment: Werkte het?

Om dit te testen, hebben de auteurs een "verborgen examen" opgezet.

Ze gaven een AI-agent de taak om een Tennisbaan Boekingssysteem te bouwen.
Ze voerden de test drie keer uit met drie verschillende instructies:
1. De "Doe Niets"-groep: De AI kreeg alleen het basisrecept (geen beveiligingsregels).
2. De "Generieke Regels"-groep: De AI kreeg het recept plus een generieke lijst met veiligheidsregels (zoals "controleer altijd wachtwoorden").
3. De "Blauwdruk"-groep: De AI kreeg het recept plus de specifieke Beveiligingsblauwdruk die op maat is gemaakt voor tennisbanen (bijv. "Een manager kan alleen banen bewerken die hij zelf beheert").

De Resultaten:
Ze testten alle drie de systemen met een verborgen reeks van 221 beveiligingstests (zoals proberen het systeem te hacken, gegevens te stelen of de regels te breken).

Groep 1 (Geen regels): Faalde 50 keer.
Groep 2 (Generieke regels): Faalde 42 keer. (Beter, maar maakte nog steeds fouten).
Groep 3 (De Blauwdruk): Faalde slechts 36 keer. (Het beste resultaat).

De grootste verbetering vond plaats in de categorie "Bedrijfslogica". Dit betekent dat de Blauwdruk de AI hielp om de specifieke regels van de tenniswereld (zoals eigendom en boekingsstatussen) veel beter te begrijpen dan wanneer er alleen algemene veiligheidsadviezen werden gegeven.

5. De Conclusie

Het artikel concludeert dat generiek veiligheidsadvies helpt, maar specifieke, gedetailleerde blauwdrukken noodzakelijk zijn.

Als je wilt dat een AI een veilig systeem bouwt, kun je niet hopen dat de AI de regels raadt. Je moet een "Beveiligingsblauwdruk" maken die de bedrijfsregels expliciet verbindt met de beveiligingsregels. Deze blauwdruk fungeert als een brug, die ervoor zorgt dat de beveiligingskennis niet verloren gaat in de vertaling wanneer de AI de code schrijft.

Kortom: Vertel de AI niet alleen wat het moet bouwen; vertel het exact hoe het moet beschermen wat het bouwt, met behulp van een gestructureerde kaart die geen ruimte laat voor twijfel.

Technische Samenvatting: Benchmark voor de Transitie van Beveiligingskennis in Specificatie-gestuurde Ontwikkeling

1. Probleemstelling

Het artikel adresseert een kritieke kloof in AI-ondersteunde specificatie-gestuurde ontwikkeling (SDD). Hoewel moderne Large Language Model (LLM) agenten steeds vaker worden gebruikt om code te genereren op basis van gestructureerde specificaties (user stories, API-contracten, technische specificaties), vindt er tijdens dit proces een significante "verlies van beveiligingskennis" plaats.

In traditionele SDD worden functionele eisen expliciet gedefinieerd (bijv. "gebruikers kunnen boekingen maken"), maar blijven beveiligingseisen vaak impliciet, generiek of worden ze uitgesteld tot de review na de generatie. Gevolgelijk voldoen gegenereerde systemen vaak wel aan zichtbare functionele eisen, maar falen ze in het behouden van kritieke beveiligingsgedragingen zoals:

Autorisatieregels en eigendomsgrenzen.
Inputvalidatie en het afwijzen van tokens.
Afhandeling van gevoelige gegevens en abuse-case semantiek.

De auteurs stellen dat het vertrouwen op de training-priors van een LLM voor beveiliging onstabiel is. Het kernprobleel is het gebrek aan een geformaliseerde methode om applicatiespecifieke beveiligingskennis in een specificatie te representeren, die kennis over te dragen naar de gegenereerde code, en die transitie te verifiëren zonder testdata naar de generator te lekken.

2. Methodologie

Het artikel stelt een tweeledige aanpak voor: een Multilayer Specification Security Model en een Security Knowledge Transition Method, geëvalueerd via twee empirische studies met een hidden-oracle en hidden-black-box benchmark-ontwerp.

A. Multilayer Specification Security Model

Dit model operationaliseert beveiligingskennis als een traceerbare structuur in plaats van een platte checklist. Het bestaat uit vijf kernlagen die verbonden zijn door een traceerbaarheidsketen (Systeementiteit → Dreiging/Risico → Vereiste → Implementatieregel → Code-element → Verificatiescenario → Bewijs):

Systeemmodel: Definieert actoren, rollen, activa, endpoints, vertrouwensgrenzen en eigendomsregels.
Threat/Risk Registry: Legt dreigingen, abuse cases en oorzaken vast die gekoppeld zijn aan specifieke activa.
Ontwerplaag: Brengt het beveiligingslandschap in kaart (beschermde activa, datastromen).
Implementatielaag: Vertaalt dreigingen naar actiegerichte regels (bijv. endpoint autorisatie, controles op objecteigendom).
Verificatielaag: Definieert positieve/negatieve tests, misuse cases en bewijseisen.

B. Security Knowledge Transition Method

Dit is een achtfasen-pipeline die zakelijke/technische specificaties transformeert naar een "beveiligingsverrijkt generatiecontract":

Specificatieverwerving: Verzamelen van vereisten en OpenAPI-contracten.
Specificatievalidatie: Waarborgen van volledigheid van actoren en eigendomsregels.
Extractie van beveiligingsrelevante informatie: Normaliseren van de systeemcontext.
Afleiding van Dreiging en Risico: Gebruikmaken van bronnen zoals OWASP ASVS en STRIDE om risico's af te leiden.
Synthese van Beveiligingseisen: Creëren van testbare, traceerbare vereisten.
Implementatie-transitie: Omzetten van vereisten in code-restricties.
Integratie: Direct injecteren van beveiligingsrestricties in de technische specificatie die door de AI-agent wordt gebruikt.
Verificatie-transitie: Afleiden van verborgen testscenario's uit de vereisten.

C. Experimenteel Ontwerp

De evaluatie maakt gebruik van een hidden-evaluator benadering om test-lekkage te voorkomen:

Studie 1 (Modelgeneratie): Een LLM-pipeline probeert een gestructureerd beveiligingsmodel af te leiden uit een systeemcontext, terwijl het oorspronkelijke threat/risk model (de "oracle") verborgen blijft.
Studie 2 (Codegeneratie): Een GPT-5.3-Codex agent genereert een FastAPI backend voor een tennisbaan-boekingssysteem onder drie condities:
- Baseline ( $C_0$ ): Alleen functionele specificatie.
- ASVS-geconditioneerd ( $C_1$ ): Functionele specificatie + OWASP ASVS vereisten.
- Multilayer Model Geconditioneerd ( $C_2$ ): Functionele specificatie + applicatiespecifiek Multilayer Security Model.
Evaluatie: Alle gegenereerde backends worden geëvalueerd tegen een verborgen 221-test black-box API suite die 15 categorieën beslaat (bijv. Admin Safety, Business Logic, Authorization).

3. Belangrijkste Bijdragen

Multilayer Specification Security Model: Een gestructureerd, door AI consumeerbaar artefact dat beveiligingskennis representeert via traceerbare relaties tussen systeementiteiten, dreigingen, vereisten en verificatiebewijs.
Security Knowledge Transition Method: Een pipeline voor het transformeren van specificaties naar gevalideerde, beveiligingsverrijkte generatiecontracten.
Empirische Validatie van Modelgeneratie: Bewijs dat een LLM-pipeline in staat is om domeinspecifieke beveiligingsaspecten af te leiden uit de systeemcontext onder hidden-oracle condities.
Code Generatie Casestudy: Empirisch bewijs dat beveiligings-conditionering het gedrag van gegenereerde backends verbetert, waarbij specifiek wordt aangetoond dat applicatiespecifieke modellering beter presteert dan generieke standaarden.

4. Resultaten

Studie 1: Beveiligingsmodelgeneratie

Dekking: Het gegenereerde model bereikte 100% relaxed coverage van de verborgen oracle (alle 11 dreigingen en 6 risico's werden ten minste gedeeltelijk gerepresenteerd).
Precisie: De strikte dekking was matig (5/11 dreigingen, 4/6 risico's volledig gedekt), waarbij de rest gedeeltelijk werd gedekt.
Conclusie: De pipeline kan de beveiligingsproblematiek herstellen, maar de gegenereerde taxonomie vereist deskundige review voor afstemming en verfijning.

Studie 2: Prestaties van Backendgeneratie

Geëvalueerd tegen de 221-test verborgen suite, waren de modale foutaantallen (meest voorkomende uitkomst over drie runs) als volgt:

Baseline ( $C_0$ ): 50 fouten (77,38% pass rate).
ASVS-geconditioneerd ( $C_1$ ): 42 fouten (81,00% pass rate).
- Relatieve reductie van fouten: 16,00% t.o.v. baseline.
Multilayer Model Geconditioneerd ( $C_2$ ): 36 fouten (83,71% pass rate).
- Relatieve reductie van fouten: 28,00% t.o.v. baseline; 14,29% t.o.v. ASVS alleen.

Analyse op Categorie-niveau:

De meest significante verbeteringen vonden plaats in applicatiespecifieke categorieën:
- Business Logic: Fouten daalden van 17 naar 9 (47,06% reductie).
- Admin Safety: Fouten daalden van 2 naar 0 (100% reductie).
- JWT Token: Fouten daalden van 1 naar 0.
Generieke Categorieën: Verbeteringen in categorieën zoals Input Validatie waren minder uitgesproken, wat suggereert dat generieke standaarden (ASVS) dit terrein al grotendeels dekken.
Regressie: Een lichte toename in "Contract Conformance" fouten (13 naar 14) werd waargenomen, toegeschreven aan het feit dat beveiligingslogica de schema-getrouwheid overschreef (bijv. het teruggeven van generieke fouten in plaats van de verwachte schema's), wat wijst op een behoefte aan geïntegreerde contract-bewuste generatie.

5. Betekenis en Claims

Het artikel claimt dat generieke beveiligingsstandaarden (zoals OWASP ASVS) het gegenereerde beveiligingsgedrag verbeteren, maar onvoldoende zijn voor applicatiespecifieke beveiligingssemantiek.

Kernargument: Beveiligingskennis moet een expliciet lifecycle-artefact zijn. Het mag niet worden overgelaten aan model-priors of post-generatie review.
Waardepropositie: Het Multilayer Specification Security Model fungeert als een intermediair artefact dat algemene beveiligingsconcepten bindt aan concrete actoren, activa, eigendomsregels en statusovergangen die specifiek zijn voor het domein.
Beperkingen: De auteurs stellen expliciet dat het model een "beveiligingseis operationalisatielaag" is, en geen garantie voor veilige code. De beste conditie faalde nog steeds op 36/221 tests, wat de noodzaak van verborgen black-box testen onderstreept. De resultaten zijn voorlopig bewijs gebaseerd op een enkele domein (tennisboekingen) en een specifieke LLM-agent, en claimen geen volledige beveiligingsgarantie of generalisatie over alle domeinen.

Het artikel concludeert dat specificatie-gestuurde AI-ontwikkeling een toegewijde beveiligingsartefactlaag vereist om het verlies van beveiligingskennis te verminderen, waarmee de kloof tussen zakelijke regels en veilige implementatie wordt overbrugd.