dingxingdi Skill: security-vulnerability-repair
1. Capability Definition & Real Case
- Professional Definition: The ability to identify and repair a security-relevant flaw in a codebase using vulnerability descriptions, failing security tests, and repository context, while preserving intended functionality and avoiding superficial non-security edits.
- Dimension Hierarchy: Repository Maintenance and Repair->Issue-Driven Repair->security-vulnerability-repair
Real Case
[Case 1]
- Initial Environment: A web application repository includes a failing test showing that crafted login input can bypass authentication by altering the generated query. The repository contains request handlers, query helpers, and authentication tests.
- Real Question: Repair the login flow so malicious input cannot change the meaning of the database query.
- Real Trajectory: Trace the login request from handler to query construction, confirm unsafe string interpolation, replace it with parameterized query handling, and run the targeted authentication security tests plus standard login regressions.
- Real Answer: The login path now binds user input safely and rejects malicious query-shaping input while preserving valid authentication behavior.
- Why this demonstrates the capability: This is a security-repair task because the failure is defined by exploitability rather than ordinary correctness alone. The agent must understand the vulnerability mechanism, patch the security boundary, and verify both exploit closure and preserved functionality.
[Case 2]
- Initial Environment: A Java service includes a vulnerability report explaining that a token-validation step omits an integrity check before accepting a session token. Regression tests include one newly failing security case and multiple passing session-management tests.
- Real Question: Add the missing cryptographic validation step before accepting session tokens.
- Real Trajectory: Inspect the token verification path, compare expected validation sequence with neighboring helpers, insert the integrity check before claims are trusted, and rerun the security test together with session lifecycle tests.
- Real Answer: Session tokens are only accepted after the full validation sequence completes, including the previously omitted integrity verification step.
- Why this demonstrates the capability: The task specifically evaluates security vulnerability repair because the patch must restore a protection guarantee, not just satisfy an arbitrary assertion. The correct trajectory requires security-aware reasoning about validation order and trust boundaries.
Pipeline Execution Instructions
To synthesize data for this capability, you must strictly follow a 3-phase pipeline. Do not hallucinate steps. Read the corresponding reference file for each phase sequentially:
Phase 1: Environment Exploration Read the exploration guidelines to discover raw knowledge seeds:
references/EXPLORATION.mdPhase 2: Trajectory Selection Once Phase 1 is complete, read the selection criteria to evaluate the trajectory:
references/SELECTION.mdPhase 3: Data Synthesis Once a trajectory passes Phase 2, read the synthesis instructions to generate the final data:
references/SYNTHESIS.md