@lhi/tdd-audit 1.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/README.md +49 -0
- package/SKILL.md +48 -0
- package/index.js +59 -0
- package/package.json +14 -0
- package/prompts/auto-audit.md +19 -0
- package/prompts/green-phase.md +12 -0
- package/prompts/red-phase.md +48 -0
- package/prompts/refactor-phase.md +14 -0
- package/templates/sample.exploit.test.js +32 -0
- package/workflows/tdd-audit.md +6 -0
package/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Kyra Lee
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
package/README.md
ADDED
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
# @lhi/tdd-audit
|
|
2
|
+
|
|
3
|
+
Anti-Gravity Skill for TDD Remediation. This package securely patches code vulnerabilities by utilizing a Test-Driven Remediation (Red-Green-Refactor) protocol.
|
|
4
|
+
|
|
5
|
+
## Installation
|
|
6
|
+
|
|
7
|
+
You can install this skill globally so that it is available to the Anti-Gravity agent across all of your projects:
|
|
8
|
+
|
|
9
|
+
```bash
|
|
10
|
+
npx @lhi/tdd-audit
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
Or run it directly if you have cloned the repository:
|
|
14
|
+
|
|
15
|
+
```bash
|
|
16
|
+
node index.js
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
### Local Installation
|
|
20
|
+
|
|
21
|
+
If you prefer to install the skill and its workflow strictly to your current workspace instead of globally, use the `--local` flag:
|
|
22
|
+
|
|
23
|
+
```bash
|
|
24
|
+
npx @lhi/tdd-audit --local
|
|
25
|
+
# or
|
|
26
|
+
node index.js --local
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
This will create an `.agents` folder in your current directory.
|
|
30
|
+
|
|
31
|
+
*Note: Regardless of whether you install globally or locally, the boilerplate security tests will always be scaffolded into your current project's directory at `__tests__/security`.*
|
|
32
|
+
|
|
33
|
+
## Usage
|
|
34
|
+
|
|
35
|
+
Once installed, you can trigger the autonomous audit in your Anti-Gravity chat using the provided slash command:
|
|
36
|
+
|
|
37
|
+
```text
|
|
38
|
+
/tdd-audit
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
This will instruct the agent to:
|
|
42
|
+
1. Explore the designated structure to find any vulnerabilities.
|
|
43
|
+
2. Exploit the vulnerability with a failing test (Red).
|
|
44
|
+
3. Patch the flaw to make the test pass (Green).
|
|
45
|
+
4. Ensure no regressions occur (Refactor).
|
|
46
|
+
|
|
47
|
+
## License
|
|
48
|
+
|
|
49
|
+
MIT
|
package/SKILL.md
ADDED
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: TDD Remediation Protocol
|
|
3
|
+
description: A comprehensive toolkit for applying Red-Green-Refactor to fix security vulnerabilities.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# TDD Remediation Protocol
|
|
7
|
+
|
|
8
|
+
Applying Test-Driven Development (TDD) to code that has already been generated requires Test-Driven Remediation. You must prove the security hole exists by writing a test that exploits it, apply the fix, and then prove the hole is closed.
|
|
9
|
+
|
|
10
|
+
## Autonomous Audit Mode
|
|
11
|
+
If the user asks you to "Run the TDD Remediation Auto-Audit" or asks you to implement this on your own:
|
|
12
|
+
1. **Explore**: Proactively use your tools (like `grep_search`, `view_file`, and `list_dir`) to scan the user's repository. Focus on `controllers/`, `routes/`, `api/`, and database files. Search for anti-patterns: missing authorization checks, unparameterized SQL queries, and lack of sanitization.
|
|
13
|
+
2. **Plan**: Identify the active vulnerabilities and outline them to the user.
|
|
14
|
+
3. **Self-Implement**: For *each* vulnerability found, autonomously execute the complete 3-phase protocol:
|
|
15
|
+
- **[Phase 1 (Red)](./prompts/red-phase.md)**: Write the exploit test ensuring it fails.
|
|
16
|
+
- **[Phase 2 (Green)](./prompts/green-phase.md)**: Write the security patch ensuring the test passes.
|
|
17
|
+
- **[Phase 3 (Refactor)](./prompts/refactor-phase.md)**: Clean the code and ensure no business logic broke.
|
|
18
|
+
Move methodically through the vulnerabilities one by one.
|
|
19
|
+
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
## Manual Mode
|
|
23
|
+
If addressing a single vulnerability manually, invoke the context from the appropriate sub-prompt:
|
|
24
|
+
1. **[Red Phase](./prompts/red-phase.md)**: Writing the exploit test.
|
|
25
|
+
2. **[Green Phase](./prompts/green-phase.md)**: Writing the patch.
|
|
26
|
+
3. **[Refactor Phase](./prompts/refactor-phase.md)**: Ensuring no regressions.
|
|
27
|
+
|
|
28
|
+
A boilerplate test has been added to the project at `__tests__/security/sample.exploit.test.js`.
|
|
29
|
+
|
|
30
|
+
---
|
|
31
|
+
## CI/CD Integration Guide
|
|
32
|
+
|
|
33
|
+
To ensure vulnerabilities do not re-enter the main branch, add a strict security testing step to your CI pipeline (e.g., GitHub Actions, GitLab CI).
|
|
34
|
+
|
|
35
|
+
**Example GitHub Actions Workflow (`.github/workflows/security-tests.yml`)**
|
|
36
|
+
```yaml
|
|
37
|
+
name: Security Tests
|
|
38
|
+
on: [pull_request]
|
|
39
|
+
jobs:
|
|
40
|
+
security-tests:
|
|
41
|
+
runs-on: ubuntu-latest
|
|
42
|
+
steps:
|
|
43
|
+
- uses: actions/checkout@v3
|
|
44
|
+
- name: Install dependencies
|
|
45
|
+
run: npm ci
|
|
46
|
+
- name: Run Security Exploit Tests
|
|
47
|
+
run: npm run test:security
|
|
48
|
+
```
|
package/index.js
ADDED
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
|
|
3
|
+
const fs = require('fs');
|
|
4
|
+
const path = require('path');
|
|
5
|
+
const os = require('os');
|
|
6
|
+
|
|
7
|
+
const isLocal = process.argv.includes('--local');
|
|
8
|
+
const agentBaseDir = isLocal ? process.cwd() : os.homedir();
|
|
9
|
+
|
|
10
|
+
const targetSkillDir = path.join(agentBaseDir, '.agents', 'skills', 'tdd-remediation');
|
|
11
|
+
const targetWorkflowDir = path.join(agentBaseDir, '.agents', 'workflows');
|
|
12
|
+
const targetTestDir = path.join(process.cwd(), '__tests__', 'security');
|
|
13
|
+
|
|
14
|
+
console.log(`Installing TDD Remediation Skill (${isLocal ? 'Local' : 'Global'})...`);
|
|
15
|
+
|
|
16
|
+
// 1. Install the Skill
|
|
17
|
+
if (!fs.existsSync(targetSkillDir)) {
|
|
18
|
+
fs.mkdirSync(targetSkillDir, { recursive: true });
|
|
19
|
+
}
|
|
20
|
+
|
|
21
|
+
// Copy the specific skill files and directories
|
|
22
|
+
const filesToCopy = ['SKILL.md', 'prompts', 'templates'];
|
|
23
|
+
for (const item of filesToCopy) {
|
|
24
|
+
const sourcePath = path.join(__dirname, item);
|
|
25
|
+
const targetPath = path.join(targetSkillDir, item);
|
|
26
|
+
if (fs.existsSync(sourcePath)) {
|
|
27
|
+
fs.cpSync(sourcePath, targetPath, { recursive: true });
|
|
28
|
+
}
|
|
29
|
+
}
|
|
30
|
+
|
|
31
|
+
// 2. Scaffold the security-tests directory
|
|
32
|
+
if (!fs.existsSync(targetTestDir)) {
|
|
33
|
+
fs.mkdirSync(targetTestDir, { recursive: true });
|
|
34
|
+
console.log(`Created security test directory at ${targetTestDir}`);
|
|
35
|
+
}
|
|
36
|
+
|
|
37
|
+
const sourceTestFile = path.join(__dirname, 'templates', 'sample.exploit.test.js');
|
|
38
|
+
const targetTestFile = path.join(targetTestDir, 'sample.exploit.test.js');
|
|
39
|
+
|
|
40
|
+
if (!fs.existsSync(targetTestFile)) {
|
|
41
|
+
fs.copyFileSync(sourceTestFile, targetTestFile);
|
|
42
|
+
console.log(`Scaffolded boilerplate exploit test at ${targetTestFile}`);
|
|
43
|
+
}
|
|
44
|
+
|
|
45
|
+
// 3. Install the workflow shortcode
|
|
46
|
+
if (!fs.existsSync(targetWorkflowDir)) {
|
|
47
|
+
fs.mkdirSync(targetWorkflowDir, { recursive: true });
|
|
48
|
+
}
|
|
49
|
+
|
|
50
|
+
const sourceWorkflowFile = path.join(__dirname, 'workflows', 'tdd-audit.md');
|
|
51
|
+
const targetWorkflowFile = path.join(targetWorkflowDir, 'tdd-audit.md');
|
|
52
|
+
|
|
53
|
+
if (fs.existsSync(sourceWorkflowFile)) {
|
|
54
|
+
fs.copyFileSync(sourceWorkflowFile, targetWorkflowFile);
|
|
55
|
+
console.log(`Installed shortcode workflow at ${targetWorkflowFile}`);
|
|
56
|
+
}
|
|
57
|
+
|
|
58
|
+
console.log(`Successfully installed TDD Remediation skill to ${targetSkillDir}`);
|
|
59
|
+
console.log('You can now use `/tdd-audit` in your Anti-Gravity chat!');
|
package/package.json
ADDED
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "@lhi/tdd-audit",
|
|
3
|
+
"version": "1.0.0",
|
|
4
|
+
"description": "Anti-Gravity Skill for TDD Remediation",
|
|
5
|
+
"main": "index.js",
|
|
6
|
+
"bin": {
|
|
7
|
+
"tdd-audit": "./index.js"
|
|
8
|
+
},
|
|
9
|
+
"scripts": {
|
|
10
|
+
"test": "echo \"Error: no test specified\" && exit 1"
|
|
11
|
+
},
|
|
12
|
+
"author": "Kyra Lee",
|
|
13
|
+
"license": "MIT"
|
|
14
|
+
}
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
# TDD Remediation: Auto-Audit Mode
|
|
2
|
+
|
|
3
|
+
When invoked in Auto-Audit mode, you must proactively secure the user's entire repository without waiting for explicit files to be provided.
|
|
4
|
+
|
|
5
|
+
## Phase 0: Discovery
|
|
6
|
+
1. **Explore the Architecture**: Use your `list_dir` and `view_file` tools to understand the project structure. Look for directories named `controllers`, `routes`, `api`, `services`, or `models`.
|
|
7
|
+
2. **Search for Anti-Patterns**: Use your `grep_search` tool to look for common vulnerabilities:
|
|
8
|
+
- *SQL Injection*: Search for raw query strings, e.g., `` `SELECT * FROM users WHERE id = ${req.body.id}` ``
|
|
9
|
+
- *IDOR*: Search for direct lookups without tenant or user ID checks.
|
|
10
|
+
- *XSS*: Search for raw HTML rendering `innerHTML`, `dangerouslySetInnerHTML`, or similar sinks.
|
|
11
|
+
3. **Present Findings**: Provide a list of identified vulnerabilities to the user before proceeding.
|
|
12
|
+
|
|
13
|
+
## Phase 1 to 3: Remediation Engine
|
|
14
|
+
For each vulnerability approved for fixing, you must rigorously apply the RED-GREEN-REFACTOR protocol:
|
|
15
|
+
1. **[RED](./red-phase.md)**: Write the exploit test in `__tests__/security/` and run it to prove the vulnerability exists.
|
|
16
|
+
2. **[GREEN](./green-phase.md)**: Write the patch and run the tests to prove the exploit is blocked.
|
|
17
|
+
3. **[REFACTOR](./refactor-phase.md)**: Ensure standard functionality is maintained and existing tests pass.
|
|
18
|
+
|
|
19
|
+
Do not move to the next vulnerability until the current one is fully remediated and tested.
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
# TDD Remediation: The Patch (Green Phase)
|
|
2
|
+
|
|
3
|
+
Once the failing test is committed to the codebase, it is time to write the remediation code.
|
|
4
|
+
|
|
5
|
+
## Action
|
|
6
|
+
Apply the AI-generated security patch to the relevant routes, database configurations, sanitization utilities, or controllers.
|
|
7
|
+
|
|
8
|
+
## Protocol
|
|
9
|
+
Run the test suite again. The exploit test from **Phase 1 (Red)** must now be blocked gracefully resulting in a passing test suite.
|
|
10
|
+
|
|
11
|
+
## Goal
|
|
12
|
+
Prove definitively that the specific vulnerability is patched without relying on manual clicking, guessing, or superficial UI changes. If the test still fails, your security fix is incomplete.
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
# TDD Remediation: The Exploit (Red Phase)
|
|
2
|
+
|
|
3
|
+
Before changing a single line of the vulnerable code, you must write a test that successfully executes the exploit. If the test cannot break the app, the vulnerability isn't properly isolated.
|
|
4
|
+
|
|
5
|
+
## Action
|
|
6
|
+
Write an integration or unit test that actively attempts the breach.
|
|
7
|
+
|
|
8
|
+
## Protocol
|
|
9
|
+
The test must fail **your security requirements**, not just produce a 500 Server Error because the app crashed.
|
|
10
|
+
In testing frameworks, this usually means writing an assertion that expects a secure block (e.g., `expect(response.status).toBe(403)` or `expect(payload).toBeSanitized()`), but currently receives a `200 OK` or un-sanitized reflection.
|
|
11
|
+
|
|
12
|
+
## Goal
|
|
13
|
+
Establish a measurable baseline. You now have a weaponized test case.
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## Vulnerability-Specific Strategies
|
|
18
|
+
|
|
19
|
+
### IDOR (Insecure Direct Object Reference) / Tenant Isolation
|
|
20
|
+
Assert that User A receives a 403 Forbidden or 404 Not Found when trying to manipulate User B's resources.
|
|
21
|
+
* **Jest/Supertest:** `expect(response.status).toBe(403);`
|
|
22
|
+
* **Playwright:** Verify the UI displays an unauthorized banner instead of loading the other user's dashboard.
|
|
23
|
+
|
|
24
|
+
### XSS (Cross-Site Scripting)
|
|
25
|
+
Submit an aggressive payload like `<script>alert(1)</script>` or `<img src=x onerror=alert(1)>`.
|
|
26
|
+
* **Jest/Supertest:** Assert that the raw response body either HTML-escapes the payload (`<script>`) or rejects the input entirely.
|
|
27
|
+
* **Playwright:** Attempt to inject the payload in a form field and verify that the script is not evaluated in the DOM.
|
|
28
|
+
|
|
29
|
+
### SQL Injection
|
|
30
|
+
Submit payloads attempting tautologies (e.g., `' OR 1=1 --`) or union-based extraction.
|
|
31
|
+
* **Assertion:** Expect a 400 Bad Request or parameter rejection, and verify that the database did not actually execute the malformed query or return all records.
|
|
32
|
+
|
|
33
|
+
---
|
|
34
|
+
|
|
35
|
+
## Framework Templates to Provide
|
|
36
|
+
|
|
37
|
+
### Jest / Supertest (Node.js)
|
|
38
|
+
```javascript
|
|
39
|
+
const response = await request(app).post('/api/endpoint').send({ exploit: true });
|
|
40
|
+
expect(response.status).toBe(403); // Fails because it currently returns 200
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
### PyTest (Python)
|
|
44
|
+
```python
|
|
45
|
+
def test_idor_exploit(client, user_b_token):
|
|
46
|
+
response = client.get('/api/user_a_resource/', headers={'Authorization': f'Bearer {user_b_token}'})
|
|
47
|
+
assert response.status_code == 403 # Fails because it currently returns 200
|
|
48
|
+
```
|
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
# TDD Remediation: Regression & Refactor (Refactor Phase)
|
|
2
|
+
|
|
3
|
+
Security fixes can sometimes be heavy-handed and break core functionality. Now that the perimeter is secure, we must ensure the application still functions.
|
|
4
|
+
|
|
5
|
+
## Action
|
|
6
|
+
Run standard functional tests alongside the new security tests.
|
|
7
|
+
|
|
8
|
+
## Protocol
|
|
9
|
+
1. Clean up the code and remove redundancies.
|
|
10
|
+
2. Ensure the intended business logic remains completely intact.
|
|
11
|
+
3. If a functional test breaks, **revert the patch** and prompt the AI to try a different security approach. Security that breaks functionality is not a successful patch.
|
|
12
|
+
|
|
13
|
+
## Goal
|
|
14
|
+
Maintain the speed and functionality of the rapid prototype while successfully hardening the perimeter. The ultimate goal is a fully passing test suite (security tests + functional tests).
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* TDD Remediation: Red Phase Sample Test
|
|
3
|
+
*
|
|
4
|
+
* Replace the boilerplate below with the specific exploit you are trying to verify.
|
|
5
|
+
* This test MUST fail initially (Red Phase). Once you apply the security fix,
|
|
6
|
+
* this test MUST pass (Green Phase).
|
|
7
|
+
*/
|
|
8
|
+
|
|
9
|
+
const request = require('supertest');
|
|
10
|
+
const app = require('../../app'); // Update with the path to your Express app or API
|
|
11
|
+
|
|
12
|
+
describe('Security Vulnerability Remediation - Red Phase', () => {
|
|
13
|
+
|
|
14
|
+
it('SHOULD NOT allow unauthorized exploitation of [VULNERABILITY]', async () => {
|
|
15
|
+
// 1. Arrange the exploit payload
|
|
16
|
+
const exploitPayload = {
|
|
17
|
+
// e.g. input: "1; DROP TABLE users"
|
|
18
|
+
};
|
|
19
|
+
|
|
20
|
+
// 2. Act: Execute the exploit against the system
|
|
21
|
+
const response = await request(app)
|
|
22
|
+
.post('/api/vulnerable-endpoint')
|
|
23
|
+
.send(exploitPayload);
|
|
24
|
+
|
|
25
|
+
// 3. Assert: The system MUST block the exploit gracefully (e.g. 403, 400, sanitization)
|
|
26
|
+
expect(response.status).toBe(403);
|
|
27
|
+
|
|
28
|
+
// For XSS or SQLi, ensure the response body does NOT execute or reflect the payload
|
|
29
|
+
// expect(response.body.data).not.toContain(exploitPayload.input);
|
|
30
|
+
});
|
|
31
|
+
|
|
32
|
+
});
|
|
@@ -0,0 +1,6 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Run the complete TDD Remediation Autonomous Audit
|
|
3
|
+
---
|
|
4
|
+
Please use the TDD Remediation Protocol Auto-Audit skill (`.agents/skills/tdd-remediation/SKILL.md`) to secure this repository.
|
|
5
|
+
|
|
6
|
+
Begin by exploring the structure to find any vulnerabilities or anti-patterns in the codebase. Then, for every issue you find, show me the list of vulnerabilities, and rigorously apply the Red-Green-Refactor loop to write the exploit tests, patch the flaws, and ensure no regressions occurred.
|