💻 computer science

Specification-Driven Development Benchmark: Security Knowledge Transition

This paper addresses the security gaps in specification-driven AI development by proposing a Multilayer Specification Security Model and a Security Knowledge Transition Method that operationalize security requirements, demonstrating through empirical studies that these approaches significantly reduce API failures compared to baseline and ASVS-conditioned generation.

Original authors: Oleg Grynets, Andrii Salyk, Vasyl Lyashkevych, Oleh Kaskun, Danyil Zhuravchak

Published 2026-06-02

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Oleg Grynets, Andrii Salyk, Vasyl Lyashkevych, Oleh Kaskun, Danyil Zhuravchak

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are hiring a super-fast, incredibly talented robot chef to build a complex restaurant kitchen for you. You give the robot a detailed recipe (the specification) that says, "Make a tennis court booking system where users can book courts, pay fees, and cancel reservations."

The robot is amazing at following the recipe. It builds the stove, the ovens, and the ordering system perfectly. However, there's a problem: you forgot to tell the robot the safety rules. You didn't say, "Don't let a customer book a court that belongs to someone else," or "Make sure a deactivated user can't sneak back in," or "Don't let someone change the price of a court after it's booked."

Because the robot wasn't explicitly told these safety rules, it builds a kitchen that works great for cooking (functional) but is dangerous (insecure). It might let anyone walk into the VIP room or let a customer steal another person's reservation.

This paper is about fixing that problem. The authors, a team from EPAM Systems, argue that when we use AI to write software, we can't just rely on the AI to "guess" the safety rules. We have to write them down explicitly, just like we do for the cooking instructions.

Here is the simple breakdown of their solution:

1. The Problem: The "Silent Safety" Gap

Currently, when we ask AI to build software, we give it a list of what the software should do (functional requirements). But we often leave out what the software should prevent (security requirements).

The Analogy: It's like telling a guard, "Let people in the building," but forgetting to say, "But don't let them into the vault." The guard does exactly what you said, but the building gets robbed.
The Result: The AI builds a system that works perfectly for the user but fails to protect data, block bad actors, or stop abuse.

2. The Solution: A "Security Blueprint" (The Multilayer Model)

The authors propose a new way of talking to the AI. Instead of just giving a recipe, they suggest giving the AI a Security Blueprint.

Think of this blueprint as a map that connects the dots between:

The Characters: (Who is the user? Who is the admin?)
The Villains: (What could go wrong? What if someone tries to steal a booking?)
The Rules: (If a user tries to steal, the system must say "No" and lock them out.)
The Test: (How do we check if the lock works?)

This blueprint isn't just a list of "be safe." It's a structured chain that says: "Because User A tries to access Resource B, and this is a risk, we must implement Rule C, and we will test it with Scenario D." This makes the security rules impossible for the AI to ignore or misunderstand.

3. The Process: Translating the Blueprint

The paper describes a method to turn a normal business plan into this security-rich blueprint before the AI starts coding.

Step 1: Look at the business plan.
Step 2: Ask the AI (or experts) to identify all the potential "villains" and risks based on that plan.
Step 3: Turn those risks into specific, unbreakable rules for the code.
Step 4: Feed this enriched plan to the AI to build the software.

4. The Experiment: Did it Work?

To test this, the authors set up a "hidden exam."

They gave an AI agent a task to build a Tennis Court Booking System.
They ran the test three times with three different instructions:
1. The "Do Nothing" Group: The AI got only the basic recipe (no security rules).
2. The "Generic Rules" Group: The AI got the recipe plus a generic list of safety rules (like "always check passwords").
3. The "Blueprint" Group: The AI got the recipe plus the specific Security Blueprint tailored to tennis courts (e.g., "A manager can only edit courts they manage").

The Results:
They tested all three systems with a hidden set of 221 security tests (like trying to hack the system, steal data, or break the rules).

Group 1 (No rules): Failed 50 times.
Group 2 (Generic rules): Failed 42 times. (Better, but still made mistakes).
Group 3 (The Blueprint): Failed only 36 times. (The best result).

The biggest improvement happened in the "Business Logic" category. This means the Blueprint helped the AI understand the specific rules of the tennis world (like ownership and booking states) much better than just giving it generic safety advice.

5. The Conclusion

The paper concludes that generic safety advice helps, but specific, detailed blueprints are necessary.

If you want an AI to build a secure system, you can't just hope it knows the rules. You have to build a "Security Blueprint" that explicitly connects the business rules to the safety rules. This blueprint acts as a bridge, ensuring that the security knowledge isn't lost in translation when the AI writes the code.

In short: Don't just tell the AI what to build; tell it exactly how to protect what it builds, using a structured map that leaves no room for guessing.

Technical Summary: Specification-Driven Development Benchmark for Security Knowledge Transition

1. Problem Statement

The paper addresses a critical gap in AI-assisted specification-driven development (SDD). While modern Large Language Model (LLM) agents are increasingly used to generate code from structured specifications (user stories, API contracts, technical specs), a significant "security knowledge loss" occurs during this process.

In traditional SDD, functional requirements are explicitly defined (e.g., "users can create bookings"), but security requirements often remain implicit, generic, or postponed to post-generation review. Consequently, generated systems frequently satisfy visible functional requirements while failing to preserve critical security behaviors such as:

Authorization rules and ownership boundaries.
Input validation and token rejection.
Sensitive data handling and abuse-case semantics.

The authors argue that relying on an LLM's training data priors for security is unstable. The core problem is the lack of a formalized method to represent application-specific security knowledge in a specification, transfer that knowledge into generated code, and verify the transition without leaking test data to the generator.

2. Methodology

The paper proposes a two-pronged approach: a Multilayer Specification Security Model and a Security Knowledge Transition Method, evaluated through two empirical studies using a hidden-oracle and hidden-black-box benchmark design.

A. Multilayer Specification Security Model

This model operationalizes security knowledge as a traceable structure rather than a flat checklist. It consists of five core layers connected by a traceability chain (System entity → Threat/Risk → Requirement → Implementation rule → Code element → Verification scenario → Evidence):

System Model: Defines actors, roles, assets, endpoints, trust boundaries, and ownership rules.
Threat/Risk Registry: Records threats, abuse cases, and root causes linked to specific assets.
Design Layer: Maps the security landscape (protected assets, data flows).
Implementation Layer: Translates threats into actionable rules (e.g., endpoint authorization, object ownership checks).
Verification Layer: Defines positive/negative tests, misuse cases, and evidence requirements.

B. Security Knowledge Transition Method

This is an eight-stage pipeline transforming business/technical specifications into a "security-enriched generation contract":

Specification Acquisition: Gathering requirements and OpenAPI contracts.
Specification Validation: Ensuring completeness of actors and ownership rules.
Security-Relevant Extraction: Normalizing the system context.
Threat and Risk Derivation: Using sources like OWASP ASVS and STRIDE to derive risks.
Security Requirement Synthesis: Creating testable, traceable requirements.
Implementation Transition: Converting requirements into code constraints.
Integration: Injecting security constraints directly into the technical specification used by the AI agent.
Verification Transition: Deriving hidden test scenarios from requirements.

C. Experimental Design

The evaluation uses a hidden-evaluator approach to prevent test leakage:

Study 1 (Model Generation): An LLM pipeline attempts to derive a structured security model from a system context while the original threat/risk model (the "oracle") remains hidden.
Study 2 (Code Generation): A GPT-5.3-Codex agent generates a FastAPI backend for a tennis court booking system under three conditions:
- Baseline ( $C_0$ ): Functional specification only.
- ASVS-Conditioned ( $C_1$ ): Functional spec + OWASP ASVS requirements.
- Multilayer Model Conditioned ( $C_2$ ): Functional spec + Application-specific Multilayer Security Model.
Evaluation: All generated backends are evaluated against a hidden 221-test black-box API suite covering 15 categories (e.g., Admin Safety, Business Logic, Authorization).

3. Key Contributions

Multilayer Specification Security Model: A structured, AI-consumable artifact representing security knowledge through traceable relations between system entities, threats, requirements, and verification evidence.
Security Knowledge Transition Method: A pipeline for transforming specifications into validated, security-enriched generation contracts.
Empirical Validation of Model Generation: Evidence that an LLM pipeline can infer domain-specific security concerns from system context under hidden-oracle conditions.
Code Generation Case Study: Empirical evidence that security-conditioning improves generated backend behavior, specifically showing that application-specific modeling outperforms generic standards.

4. Results

Study 1: Security Model Generation

Coverage: The generated model achieved 100% relaxed coverage of the hidden oracle (all 11 threats and 6 risks were at least partially represented).
Precision: Strict coverage was moderate (5/11 threats, 4/6 risks fully covered), with the remainder partially covered.
Conclusion: The pipeline can recover the security concern space, but the generated taxonomy requires expert review for alignment and refinement.

Study 2: Backend Generation Performance

Evaluated against the 221-test hidden suite, the modal failure counts (most frequent outcome across three runs) were:

Baseline ( $C_0$ ): 50 failures (77.38% pass rate).
ASVS-Conditioned ( $C_1$ ): 42 failures (81.00% pass rate).
- Relative Failure Reduction: 16.00% vs. baseline.
Multilayer Model Conditioned ( $C_2$ ): 36 failures (83.71% pass rate).
- Relative Failure Reduction: 28.00% vs. baseline; 14.29% vs. ASVS alone.

Category-Level Analysis:

The most significant improvements occurred in application-specific categories:
- Business Logic: Failures dropped from 17 to 9 (47.06% reduction).
- Admin Safety: Failures dropped from 2 to 0 (100% reduction).
- JWT Token: Failures dropped from 1 to 0.
Generic Categories: Improvements in categories like Input Validation were less pronounced, suggesting generic standards (ASVS) already cover much of this ground.
Regression: A slight increase in "Contract Conformance" failures (13 to 14) was observed, attributed to security logic overriding schema fidelity (e.g., returning generic errors instead of expected schemas), indicating a need for integrated contract-aware generation.

5. Significance and Claims

The paper claims that generic security standards (like OWASP ASVS) improve generated security behavior but are insufficient for application-specific security semantics.

Core Argument: Security knowledge must be an explicit lifecycle artifact. It should not be left to model priors or post-generation review.
Value Proposition: The Multilayer Specification Security Model acts as an intermediate artifact that binds general security concepts to concrete actors, assets, ownership rules, and state transitions specific to the domain.
Limitations: The authors explicitly state that the model is a "security-requirement operationalization layer," not a guarantee of secure code. The best condition still failed 36/221 tests, necessitating hidden black-box testing. The results are preliminary evidence based on a single domain (tennis booking) and a specific LLM agent, and do not claim complete security assurance or generalization across all domains.

The paper concludes that specification-driven AI development requires a dedicated security artifact layer to reduce observable security-knowledge loss, bridging the gap between business rules and secure implementation.