@harness-engineering/cli 1.6.0 → 1.6.2
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/dist/agents/personas/code-reviewer.yaml +2 -0
- package/dist/agents/personas/codebase-health-analyst.yaml +5 -0
- package/dist/agents/personas/performance-guardian.yaml +26 -0
- package/dist/agents/personas/security-reviewer.yaml +35 -0
- package/dist/agents/skills/claude-code/harness-autopilot/SKILL.md +494 -0
- package/dist/agents/skills/claude-code/harness-autopilot/skill.yaml +52 -0
- package/dist/agents/skills/claude-code/harness-code-review/SKILL.md +15 -0
- package/dist/agents/skills/claude-code/harness-integrity/SKILL.md +20 -6
- package/dist/agents/skills/claude-code/harness-perf/SKILL.md +231 -0
- package/dist/agents/skills/claude-code/harness-perf/skill.yaml +47 -0
- package/dist/agents/skills/claude-code/harness-perf-tdd/SKILL.md +236 -0
- package/dist/agents/skills/claude-code/harness-perf-tdd/skill.yaml +47 -0
- package/dist/agents/skills/claude-code/harness-pre-commit-review/SKILL.md +27 -2
- package/dist/agents/skills/claude-code/harness-release-readiness/SKILL.md +657 -0
- package/dist/agents/skills/claude-code/harness-release-readiness/skill.yaml +57 -0
- package/dist/agents/skills/claude-code/harness-security-review/SKILL.md +206 -0
- package/dist/agents/skills/claude-code/harness-security-review/skill.yaml +50 -0
- package/dist/agents/skills/claude-code/harness-security-scan/SKILL.md +102 -0
- package/dist/agents/skills/claude-code/harness-security-scan/skill.yaml +41 -0
- package/dist/agents/skills/claude-code/harness-state-management/SKILL.md +22 -8
- package/dist/agents/skills/gemini-cli/harness-autopilot/SKILL.md +494 -0
- package/dist/agents/skills/gemini-cli/harness-autopilot/skill.yaml +52 -0
- package/dist/agents/skills/gemini-cli/harness-perf/SKILL.md +231 -0
- package/dist/agents/skills/gemini-cli/harness-perf/skill.yaml +47 -0
- package/dist/agents/skills/gemini-cli/harness-perf-tdd/SKILL.md +236 -0
- package/dist/agents/skills/gemini-cli/harness-perf-tdd/skill.yaml +47 -0
- package/dist/agents/skills/gemini-cli/harness-release-readiness/SKILL.md +657 -0
- package/dist/agents/skills/gemini-cli/harness-release-readiness/skill.yaml +57 -0
- package/dist/agents/skills/gemini-cli/harness-security-review/skill.yaml +50 -0
- package/dist/agents/skills/gemini-cli/harness-security-scan/SKILL.md +102 -0
- package/dist/agents/skills/gemini-cli/harness-security-scan/skill.yaml +41 -0
- package/dist/bin/harness.js +3 -2
- package/dist/{chunk-VS4OTOKZ.js → chunk-IUFFBBYV.js} +1271 -461
- package/dist/{chunk-3U5VZYR7.js → chunk-UDWGSL3T.js} +4 -1
- package/dist/chunk-USEYPS7F.js +6150 -0
- package/dist/dist-4MYPT3OE.js +2528 -0
- package/dist/dist-RBZXXJHG.js +242 -0
- package/dist/index.js +3 -2
- package/dist/validate-cross-check-CPEPNLOD.js +7 -0
- package/package.json +12 -8
- package/dist/validate-cross-check-LNIZ7KGZ.js +0 -6
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
name: harness-release-readiness
|
|
2
|
+
version: "1.0.0"
|
|
3
|
+
description: Audit npm release readiness, run maintenance checks, offer auto-fixes, track progress across sessions
|
|
4
|
+
cognitive_mode: meticulous-verifier
|
|
5
|
+
triggers:
|
|
6
|
+
- manual
|
|
7
|
+
- on_milestone
|
|
8
|
+
platforms:
|
|
9
|
+
- claude-code
|
|
10
|
+
- gemini-cli
|
|
11
|
+
tools:
|
|
12
|
+
- Bash
|
|
13
|
+
- Read
|
|
14
|
+
- Write
|
|
15
|
+
- Edit
|
|
16
|
+
- Glob
|
|
17
|
+
- Grep
|
|
18
|
+
cli:
|
|
19
|
+
command: harness skill run harness-release-readiness
|
|
20
|
+
args:
|
|
21
|
+
- name: path
|
|
22
|
+
description: Project root path
|
|
23
|
+
required: false
|
|
24
|
+
- name: comprehensive
|
|
25
|
+
description: Run comprehensive checks (API docs, examples, dep health, git hygiene)
|
|
26
|
+
type: boolean
|
|
27
|
+
required: false
|
|
28
|
+
mcp:
|
|
29
|
+
tool: run_skill
|
|
30
|
+
input:
|
|
31
|
+
skill: harness-release-readiness
|
|
32
|
+
path: string
|
|
33
|
+
type: rigid
|
|
34
|
+
phases:
|
|
35
|
+
- name: audit
|
|
36
|
+
description: Run release-specific checks (packaging, docs, repo hygiene, CI/CD)
|
|
37
|
+
required: true
|
|
38
|
+
- name: maintain
|
|
39
|
+
description: Dispatch maintenance skills in parallel and collect results
|
|
40
|
+
required: true
|
|
41
|
+
- name: fix
|
|
42
|
+
description: Offer auto-remediation for fixable findings
|
|
43
|
+
required: true
|
|
44
|
+
- name: report
|
|
45
|
+
description: Generate report and persist state for session resumption
|
|
46
|
+
required: true
|
|
47
|
+
state:
|
|
48
|
+
persistent: true
|
|
49
|
+
files:
|
|
50
|
+
- .harness/release-readiness.json
|
|
51
|
+
depends_on:
|
|
52
|
+
- detect-doc-drift
|
|
53
|
+
- cleanup-dead-code
|
|
54
|
+
- align-documentation
|
|
55
|
+
- enforce-architecture
|
|
56
|
+
- harness-diagnostics
|
|
57
|
+
- harness-parallel-agents
|
|
@@ -0,0 +1,206 @@
|
|
|
1
|
+
# Harness Security Review
|
|
2
|
+
|
|
3
|
+
> Deep security audit combining mechanical scanning with AI-powered vulnerability analysis. OWASP baseline + stack-adaptive rules + optional threat modeling.
|
|
4
|
+
|
|
5
|
+
## When to Use
|
|
6
|
+
|
|
7
|
+
- Before a release or security-sensitive merge
|
|
8
|
+
- After updating dependencies (supply chain risk)
|
|
9
|
+
- When auditing a new or unfamiliar codebase
|
|
10
|
+
- When `on_pr` triggers fire on security-sensitive paths
|
|
11
|
+
- NOT for quick pre-commit checks (use harness-pre-commit-review for that)
|
|
12
|
+
- NOT for general code review (use harness-code-review for that)
|
|
13
|
+
|
|
14
|
+
## Principle: Layered Security
|
|
15
|
+
|
|
16
|
+
This skill follows the Deterministic-vs-LLM Responsibility Split principle. The mechanical scanner runs first and catches what patterns can catch. The AI review then looks for semantic issues that patterns miss — user input flowing through multiple functions to a dangerous sink, missing authorization checks, logic flaws in authentication flows.
|
|
17
|
+
|
|
18
|
+
## Process
|
|
19
|
+
|
|
20
|
+
### Phase 1: SCAN — Mechanical Security Scanner
|
|
21
|
+
|
|
22
|
+
Run the built-in security scanner against the project.
|
|
23
|
+
|
|
24
|
+
1. **Run the scanner.** Use the `run_security_scan` MCP tool or invoke `SecurityScanner` directly:
|
|
25
|
+
|
|
26
|
+
```bash
|
|
27
|
+
# Via MCP
|
|
28
|
+
harness scan --security
|
|
29
|
+
|
|
30
|
+
# Via CLI
|
|
31
|
+
npx vitest run packages/core/tests/security/
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
2. **Review findings.** Categorize by severity:
|
|
35
|
+
- **Error (blocking):** Must fix before merge — secrets, injection, eval, weak crypto
|
|
36
|
+
- **Warning (review):** Should fix — CORS wildcards, disabled TLS, path traversal patterns
|
|
37
|
+
- **Info (note):** Consider — HTTP URLs, missing security headers
|
|
38
|
+
|
|
39
|
+
3. **Report mechanical findings.** Present each finding with:
|
|
40
|
+
- Rule ID and name
|
|
41
|
+
- File, line number, matched code
|
|
42
|
+
- Remediation guidance
|
|
43
|
+
- CWE/OWASP reference
|
|
44
|
+
|
|
45
|
+
### Phase 2: REVIEW — AI-Powered Security Analysis
|
|
46
|
+
|
|
47
|
+
After mechanical scanning, perform deeper AI analysis.
|
|
48
|
+
|
|
49
|
+
#### OWASP Baseline (always runs)
|
|
50
|
+
|
|
51
|
+
Review the codebase against OWASP Top 10 and CWE Top 25:
|
|
52
|
+
|
|
53
|
+
1. **Injection (CWE-89, CWE-78, CWE-79):** Look for user input flowing to SQL queries, shell commands, or HTML output without sanitization. Trace data flow across function boundaries — patterns only catch single-line issues.
|
|
54
|
+
|
|
55
|
+
2. **Broken Authentication (CWE-287):** Check for weak session management, missing MFA enforcement, hardcoded credentials, predictable tokens.
|
|
56
|
+
|
|
57
|
+
3. **Sensitive Data Exposure (CWE-200):** Look for PII logged to console/files, sensitive data in error messages, missing encryption for data at rest or in transit.
|
|
58
|
+
|
|
59
|
+
4. **Broken Access Control (CWE-862):** Check for missing authorization on API endpoints, IDOR vulnerabilities, privilege escalation paths.
|
|
60
|
+
|
|
61
|
+
5. **Security Misconfiguration (CWE-16):** Check for debug mode in production configs, default credentials, overly permissive CORS, missing security headers.
|
|
62
|
+
|
|
63
|
+
#### Stack-Adaptive Review (based on detected tech)
|
|
64
|
+
|
|
65
|
+
After the OWASP baseline, add stack-specific checks:
|
|
66
|
+
|
|
67
|
+
- **Node.js:** Prototype pollution via `Object.assign` or spread on user input, `__proto__` injection, unhandled promise rejections exposing stack traces
|
|
68
|
+
- **Express:** Missing helmet, rate limiting, CSRF protection, body parser limits
|
|
69
|
+
- **React:** XSS via `dangerouslySetInnerHTML`, sensitive data in client state, insecure `postMessage` listeners
|
|
70
|
+
- **Go:** Race conditions in concurrent handlers, `unsafe.Pointer` usage, format string injection
|
|
71
|
+
|
|
72
|
+
### Phase 3: THREAT-MODEL (optional, `--deep` flag)
|
|
73
|
+
|
|
74
|
+
When invoked with `--deep`, build a lightweight threat model:
|
|
75
|
+
|
|
76
|
+
1. **Identify entry points.** Find all HTTP routes, API endpoints, message handlers, CLI commands, and file upload handlers.
|
|
77
|
+
|
|
78
|
+
2. **Map trust boundaries.** Where does data cross from untrusted (user input, external APIs) to trusted (database queries, file system, internal services)?
|
|
79
|
+
|
|
80
|
+
3. **Trace data flows.** For each entry point, trace how user-controlled data flows through the system. Use the knowledge graph if available (`query_graph`, `get_relationships`).
|
|
81
|
+
|
|
82
|
+
4. **Identify threat scenarios.** For each trust boundary crossing, ask:
|
|
83
|
+
- What if this input is malicious?
|
|
84
|
+
- What is the worst-case impact?
|
|
85
|
+
- What controls are in place?
|
|
86
|
+
|
|
87
|
+
5. **Report threat model.** Present as a table:
|
|
88
|
+
| Entry Point | Data Flow | Trust Boundary | Threats | Controls | Risk |
|
|
89
|
+
|-------------|-----------|----------------|---------|----------|------|
|
|
90
|
+
|
|
91
|
+
### Phase 4: REPORT — Consolidated Findings
|
|
92
|
+
|
|
93
|
+
Produce a unified security report:
|
|
94
|
+
|
|
95
|
+
```
|
|
96
|
+
Security Review: [PASS/WARN/FAIL]
|
|
97
|
+
|
|
98
|
+
Mechanical Scanner:
|
|
99
|
+
- Scanned: N files, M rules applied
|
|
100
|
+
- Coverage: baseline/enhanced
|
|
101
|
+
- Errors: N | Warnings: N | Info: N
|
|
102
|
+
|
|
103
|
+
[List each finding with rule ID, file:line, severity, and remediation]
|
|
104
|
+
|
|
105
|
+
AI Review:
|
|
106
|
+
- OWASP Baseline: [findings or "No issues found"]
|
|
107
|
+
- Stack-Adaptive ([detected stacks]): [findings or "No issues found"]
|
|
108
|
+
|
|
109
|
+
[If --deep]
|
|
110
|
+
Threat Model:
|
|
111
|
+
- Entry points: N
|
|
112
|
+
- Trust boundaries: N
|
|
113
|
+
- High-risk flows: [list]
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
## Harness Integration
|
|
117
|
+
|
|
118
|
+
- **`run_security_scan` MCP tool** — Run the mechanical scanner programmatically
|
|
119
|
+
- **`harness validate`** — Standard project health check
|
|
120
|
+
- **`query_graph` / `get_relationships`** — Used in threat modeling phase for data flow tracing
|
|
121
|
+
- **`get_impact`** — Understand blast radius of security-sensitive changes
|
|
122
|
+
|
|
123
|
+
## Gates
|
|
124
|
+
|
|
125
|
+
- **Mechanical scanner must run before AI review.** The scanner catches what patterns can catch; AI reviews what remains.
|
|
126
|
+
- **Error-severity findings are blocking.** The report must be FAIL if any error-severity finding exists.
|
|
127
|
+
- **AI review must reference specific code.** No vague warnings like "consider improving security." Every finding must point to a file, line, and specific issue.
|
|
128
|
+
- **Threat model is optional.** Only runs with `--deep`. Do not run it unless explicitly requested.
|
|
129
|
+
|
|
130
|
+
## Success Criteria
|
|
131
|
+
|
|
132
|
+
- Mechanical scanner ran and produced findings (or confirmed clean)
|
|
133
|
+
- AI review covered OWASP Top 10 baseline
|
|
134
|
+
- Stack-adaptive checks matched the detected technology
|
|
135
|
+
- Every finding includes file, line, CWE reference, and remediation
|
|
136
|
+
- Report follows the structured format
|
|
137
|
+
- Error-severity findings result in FAIL status
|
|
138
|
+
|
|
139
|
+
## Escalation
|
|
140
|
+
|
|
141
|
+
- **Scanner finds secrets in committed code:** Flag immediately. Recommend rotating the compromised credentials. This is urgent regardless of other findings.
|
|
142
|
+
- **AI review finds a critical vulnerability (RCE, SQLi, auth bypass):** Mark as blocking. Do not approve the PR. Provide exact remediation code.
|
|
143
|
+
- **Conflict between scanner and AI review:** If the scanner flags something the AI thinks is a false positive, include both perspectives in the report. Let the human decide.
|
|
144
|
+
- **Scope too large for meaningful review:** If the project has >1000 source files, recommend scoping the review to changed files or a specific subsystem.
|
|
145
|
+
|
|
146
|
+
## Examples
|
|
147
|
+
|
|
148
|
+
### Example: Clean Scan
|
|
149
|
+
|
|
150
|
+
```
|
|
151
|
+
Security Review: PASS
|
|
152
|
+
|
|
153
|
+
Mechanical Scanner:
|
|
154
|
+
- Scanned: 42 files, 22 rules applied
|
|
155
|
+
- Coverage: baseline
|
|
156
|
+
- Errors: 0 | Warnings: 0 | Info: 0
|
|
157
|
+
|
|
158
|
+
AI Review:
|
|
159
|
+
- OWASP Baseline: No issues found
|
|
160
|
+
- Stack-Adaptive (node, express): No issues found
|
|
161
|
+
```
|
|
162
|
+
|
|
163
|
+
### Example: Findings Detected
|
|
164
|
+
|
|
165
|
+
```
|
|
166
|
+
Security Review: FAIL
|
|
167
|
+
|
|
168
|
+
Mechanical Scanner:
|
|
169
|
+
- Scanned: 42 files, 22 rules applied
|
|
170
|
+
- Coverage: baseline
|
|
171
|
+
- Errors: 2 | Warnings: 1 | Info: 0
|
|
172
|
+
|
|
173
|
+
Findings:
|
|
174
|
+
1. [SEC-SEC-002] ERROR src/config.ts:12 — Hardcoded API key or secret detected
|
|
175
|
+
Remediation: Use environment variables: process.env.API_KEY
|
|
176
|
+
2. [SEC-INJ-002] ERROR src/db.ts:45 — SQL query built with string concatenation
|
|
177
|
+
Remediation: Use parameterized queries: query("SELECT * FROM users WHERE id = $1", [id])
|
|
178
|
+
3. [SEC-NET-001] WARNING src/cors.ts:8 — CORS wildcard origin allows any website to make requests
|
|
179
|
+
Remediation: Restrict CORS to specific trusted origins
|
|
180
|
+
|
|
181
|
+
AI Review:
|
|
182
|
+
- OWASP Baseline: 1 finding — user input from req.params.id flows through formatQuery() to db.execute() without sanitization (confirms SEC-INJ-002 with data flow trace)
|
|
183
|
+
- Stack-Adaptive (node, express): Missing helmet middleware, missing rate limiting on /api/* routes
|
|
184
|
+
```
|
|
185
|
+
|
|
186
|
+
### Example: Deep Audit with Threat Model
|
|
187
|
+
|
|
188
|
+
```
|
|
189
|
+
Security Review: WARN
|
|
190
|
+
|
|
191
|
+
Mechanical Scanner:
|
|
192
|
+
- Scanned: 120 files, 30 rules applied
|
|
193
|
+
- Coverage: baseline
|
|
194
|
+
- Errors: 0 | Warnings: 2 | Info: 3
|
|
195
|
+
|
|
196
|
+
AI Review:
|
|
197
|
+
- OWASP Baseline: No critical issues
|
|
198
|
+
- Stack-Adaptive (node, react): localStorage used for session token (SEC-REACT-001)
|
|
199
|
+
|
|
200
|
+
Threat Model:
|
|
201
|
+
- Entry points: 12 (8 REST endpoints, 2 WebSocket handlers, 2 CLI commands)
|
|
202
|
+
- Trust boundaries: 4 (client→API, API→database, API→external service, CLI→filesystem)
|
|
203
|
+
- High-risk flows:
|
|
204
|
+
1. POST /api/upload → file stored to disk without size limit or type validation
|
|
205
|
+
2. WebSocket message handler passes user data to eval-like template engine
|
|
206
|
+
```
|
|
@@ -0,0 +1,50 @@
|
|
|
1
|
+
name: harness-security-review
|
|
2
|
+
version: "1.0.0"
|
|
3
|
+
description: Deep security audit with OWASP baseline and stack-adaptive analysis
|
|
4
|
+
cognitive_mode: meticulous-implementer
|
|
5
|
+
triggers:
|
|
6
|
+
- manual
|
|
7
|
+
- on_pr
|
|
8
|
+
platforms:
|
|
9
|
+
- claude-code
|
|
10
|
+
- gemini-cli
|
|
11
|
+
tools:
|
|
12
|
+
- Bash
|
|
13
|
+
- Read
|
|
14
|
+
- Write
|
|
15
|
+
- Edit
|
|
16
|
+
- Glob
|
|
17
|
+
- Grep
|
|
18
|
+
cli:
|
|
19
|
+
command: harness skill run harness-security-review
|
|
20
|
+
args:
|
|
21
|
+
- name: path
|
|
22
|
+
description: Project root path
|
|
23
|
+
required: false
|
|
24
|
+
- name: deep
|
|
25
|
+
description: Enable threat modeling phase
|
|
26
|
+
required: false
|
|
27
|
+
mcp:
|
|
28
|
+
tool: run_skill
|
|
29
|
+
input:
|
|
30
|
+
skill: harness-security-review
|
|
31
|
+
path: string
|
|
32
|
+
type: rigid
|
|
33
|
+
phases:
|
|
34
|
+
- name: scan
|
|
35
|
+
description: Run mechanical security scanner
|
|
36
|
+
required: true
|
|
37
|
+
- name: review
|
|
38
|
+
description: AI-powered security review (OWASP + stack-adaptive)
|
|
39
|
+
required: true
|
|
40
|
+
- name: threat-model
|
|
41
|
+
description: Lightweight threat model from codebase graph
|
|
42
|
+
required: false
|
|
43
|
+
- name: report
|
|
44
|
+
description: Generate findings report with remediation guidance
|
|
45
|
+
required: true
|
|
46
|
+
state:
|
|
47
|
+
persistent: false
|
|
48
|
+
files: []
|
|
49
|
+
depends_on:
|
|
50
|
+
- harness-code-review
|
|
@@ -0,0 +1,102 @@
|
|
|
1
|
+
# Harness Security Scan
|
|
2
|
+
|
|
3
|
+
> Lightweight mechanical security scan. Fast triage, not deep review.
|
|
4
|
+
|
|
5
|
+
## When to Use
|
|
6
|
+
|
|
7
|
+
- As part of the codebase-health-analyst sweep
|
|
8
|
+
- For quick security triage on a project or changed files
|
|
9
|
+
- On scheduled cron runs for continuous security coverage
|
|
10
|
+
- NOT for deep security review (use harness-security-review)
|
|
11
|
+
- NOT for threat modeling (use harness-security-review --deep)
|
|
12
|
+
|
|
13
|
+
## Process
|
|
14
|
+
|
|
15
|
+
### Phase 1: SCAN — Run Mechanical Scanner
|
|
16
|
+
|
|
17
|
+
1. **Resolve project root.** Use provided path or cwd.
|
|
18
|
+
|
|
19
|
+
2. **Load security config.** Read `harness.config.json` and extract `security`
|
|
20
|
+
section. Fall back to defaults if absent.
|
|
21
|
+
|
|
22
|
+
3. **Determine file scope.**
|
|
23
|
+
- If `--changed-only` or triggered by PR: run `git diff --name-only HEAD~1`
|
|
24
|
+
to get changed files. Filter to source files only (exclude node_modules,
|
|
25
|
+
dist, test files per config).
|
|
26
|
+
- Otherwise: scan all source files in the project.
|
|
27
|
+
|
|
28
|
+
4. **Run SecurityScanner.** Call `SecurityScanner.scanFiles()` from
|
|
29
|
+
`@harness-engineering/core`.
|
|
30
|
+
|
|
31
|
+
5. **Filter by severity threshold.** Remove findings below the configured
|
|
32
|
+
threshold:
|
|
33
|
+
- `error`: only errors
|
|
34
|
+
- `warning`: errors and warnings (default)
|
|
35
|
+
- `info`: all findings
|
|
36
|
+
|
|
37
|
+
6. **Output report.** Present findings grouped by severity:
|
|
38
|
+
|
|
39
|
+
```
|
|
40
|
+
Security Scan: [PASS/FAIL]
|
|
41
|
+
Scanned: N files, M rules applied
|
|
42
|
+
Errors: N | Warnings: N | Info: N
|
|
43
|
+
|
|
44
|
+
[List findings with rule ID, file:line, severity, message, remediation]
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
## Gates
|
|
48
|
+
|
|
49
|
+
- **Error-severity findings are blocking.** Report is FAIL if any error-severity
|
|
50
|
+
finding exists after filtering.
|
|
51
|
+
- **No AI review.** This skill is mechanical only. Do not perform OWASP analysis
|
|
52
|
+
or threat modeling.
|
|
53
|
+
|
|
54
|
+
## Harness Integration
|
|
55
|
+
|
|
56
|
+
- **`harness check-security`** — CLI command that invokes this skill's scanner.
|
|
57
|
+
- **`SecurityScanner`** — Core class from `@harness-engineering/core` that executes the rule engine.
|
|
58
|
+
- **`harness.config.json`** — Security section configures severity threshold and file exclusions.
|
|
59
|
+
- **codebase-health-analyst persona** — Invokes this skill as part of its sweep.
|
|
60
|
+
|
|
61
|
+
## Escalation
|
|
62
|
+
|
|
63
|
+
- **When error-severity findings are disputed:** The scanner is mechanical — it may flag false positives. If a finding is a false positive, add a `// harness-ignore SEC-XXX` comment on the line and document the rationale. Do not suppress without explanation.
|
|
64
|
+
- **When the scanner misses a known vulnerability:** This skill runs pattern-based rules only. For semantic analysis (taint tracking, control flow), use `/harness:security-review` instead.
|
|
65
|
+
- **When scan is too slow on large codebases:** Use `--changed-only` to scope to recently changed files. Full scans can run on a scheduled cron instead.
|
|
66
|
+
|
|
67
|
+
## Success Criteria
|
|
68
|
+
|
|
69
|
+
- Scanner ran and produced findings (or confirmed clean)
|
|
70
|
+
- Findings are filtered by the configured severity threshold
|
|
71
|
+
- Report follows the structured format
|
|
72
|
+
- Exit code reflects pass/fail status
|
|
73
|
+
|
|
74
|
+
## Examples
|
|
75
|
+
|
|
76
|
+
### Example: Clean Scan
|
|
77
|
+
|
|
78
|
+
```
|
|
79
|
+
Security Scan: PASS
|
|
80
|
+
Scanned: 42 files, 12 rules applied
|
|
81
|
+
Errors: 0 | Warnings: 0 | Info: 0
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
### Example: Findings Detected
|
|
85
|
+
|
|
86
|
+
```
|
|
87
|
+
Security Scan: FAIL
|
|
88
|
+
Scanned: 42 files, 12 rules applied
|
|
89
|
+
Errors: 1 | Warnings: 2 | Info: 0
|
|
90
|
+
|
|
91
|
+
[SEC-SECRET-001] src/config.ts:15 (error)
|
|
92
|
+
Hardcoded API key detected: `const API_KEY = "sk-..."`
|
|
93
|
+
Remediation: Move to environment variable, use dotenv or secrets manager.
|
|
94
|
+
|
|
95
|
+
[SEC-NET-001] src/cors.ts:5 (warning)
|
|
96
|
+
CORS wildcard origin: `origin: "*"`
|
|
97
|
+
Remediation: Restrict to specific allowed origins.
|
|
98
|
+
|
|
99
|
+
[SEC-CRYPTO-001] src/auth.ts:22 (warning)
|
|
100
|
+
Weak hash algorithm: `crypto.createHash("md5")`
|
|
101
|
+
Remediation: Use SHA-256 or stronger.
|
|
102
|
+
```
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
name: harness-security-scan
|
|
2
|
+
version: "1.0.0"
|
|
3
|
+
description: Lightweight mechanical security scan for health checks
|
|
4
|
+
cognitive_mode: meticulous-implementer
|
|
5
|
+
triggers:
|
|
6
|
+
- manual
|
|
7
|
+
- scheduled
|
|
8
|
+
platforms:
|
|
9
|
+
- claude-code
|
|
10
|
+
- gemini-cli
|
|
11
|
+
tools:
|
|
12
|
+
- Bash
|
|
13
|
+
- Read
|
|
14
|
+
- Glob
|
|
15
|
+
- Grep
|
|
16
|
+
cli:
|
|
17
|
+
command: harness skill run harness-security-scan
|
|
18
|
+
args:
|
|
19
|
+
- name: path
|
|
20
|
+
description: Project root path
|
|
21
|
+
required: false
|
|
22
|
+
- name: severity
|
|
23
|
+
description: Minimum severity threshold (error, warning, info)
|
|
24
|
+
required: false
|
|
25
|
+
- name: changed-only
|
|
26
|
+
description: Only scan git-changed files
|
|
27
|
+
required: false
|
|
28
|
+
mcp:
|
|
29
|
+
tool: run_skill
|
|
30
|
+
input:
|
|
31
|
+
skill: harness-security-scan
|
|
32
|
+
path: string
|
|
33
|
+
type: rigid
|
|
34
|
+
phases:
|
|
35
|
+
- name: scan
|
|
36
|
+
description: Run SecurityScanner and filter by severity threshold
|
|
37
|
+
required: true
|
|
38
|
+
state:
|
|
39
|
+
persistent: false
|
|
40
|
+
files: []
|
|
41
|
+
depends_on: []
|
|
@@ -18,6 +18,13 @@
|
|
|
18
18
|
|
|
19
19
|
### Phase 1: LOAD — Restore Context from Previous Sessions
|
|
20
20
|
|
|
21
|
+
0. **Resolve the stream.** State is organized into streams — isolated directories under `.harness/streams/<name>/`. Before loading any state files:
|
|
22
|
+
- If you know which work item you're resuming, pass `--stream <name>` or use `manage_state` with `stream: "<name>"`.
|
|
23
|
+
- Otherwise, the system auto-resolves from the current git branch (e.g., `feature/auth-rework` → `auth-rework` stream) or falls back to the active stream.
|
|
24
|
+
- If resolution fails, ask the user: "Which stream should I use?" and list known streams via `harness state streams list` or the `list_streams` MCP tool.
|
|
25
|
+
- When starting new work on a new branch, create a new stream: `harness state streams create <name> --branch <branch>`.
|
|
26
|
+
- Announce which stream was resolved so the human has visibility.
|
|
27
|
+
|
|
21
28
|
1. **Read `.harness/state.json`.** This is the primary state file. It contains:
|
|
22
29
|
- Current position (phase, task, step)
|
|
23
30
|
- Progress map (which tasks are complete, in progress, or blocked)
|
|
@@ -159,7 +166,9 @@
|
|
|
159
166
|
|
|
160
167
|
2. **Verify learnings were captured.** Review `.harness/learnings.md` — were all non-obvious discoveries recorded? If something was tricky during the session, it should be in learnings.
|
|
161
168
|
|
|
162
|
-
3. **
|
|
169
|
+
3. **State is saved to the active stream.** All writes (state, learnings, handoff, failures) go to the resolved stream's directory (e.g., `.harness/streams/auth-rework/state.json`). Switching to a different stream in the next session does not affect the current stream's files.
|
|
170
|
+
|
|
171
|
+
4. **Decide whether to commit state files.** State files (`.harness/streams/*/state.json`, `.harness/streams/*/learnings.md`) should be committed to git so other team members and agents can access them. Commit state updates separately from code changes so they do not clutter code diffs.
|
|
163
172
|
|
|
164
173
|
### Building Institutional Knowledge Over Time
|
|
165
174
|
|
|
@@ -181,13 +190,18 @@ Treat learnings as a first-class project artifact. They are as valuable as tests
|
|
|
181
190
|
|
|
182
191
|
## Harness Integration
|
|
183
192
|
|
|
184
|
-
- **`harness state show`** — Display current state in a formatted, readable view. Use at session start to quickly orient.
|
|
185
|
-
- **`harness state reset`** — Reset state to initial values. Use when starting a completely new effort and old state is no longer relevant. Use with caution — this discards progress tracking.
|
|
186
|
-
- **`harness state learn "<message>"`** — Append a learning
|
|
187
|
-
-
|
|
188
|
-
-
|
|
189
|
-
-
|
|
190
|
-
-
|
|
193
|
+
- **`harness state show [--stream <name>]`** — Display current state in a formatted, readable view. Use at session start to quickly orient.
|
|
194
|
+
- **`harness state reset [--stream <name>]`** — Reset state to initial values. Use when starting a completely new effort and old state is no longer relevant. Use with caution — this discards progress tracking.
|
|
195
|
+
- **`harness state learn "<message>" [--stream <name>]`** — Append a learning with automatic timestamp formatting.
|
|
196
|
+
- **`harness state streams list`** — List all known streams with branch associations and active status.
|
|
197
|
+
- **`harness state streams create <name> [--branch <branch>]`** — Create a new stream, optionally associated with a git branch.
|
|
198
|
+
- **`harness state streams archive <name>`** — Archive a completed stream.
|
|
199
|
+
- **`harness state streams activate <name>`** — Set the active stream for the project.
|
|
200
|
+
- **`.harness/streams/<name>/state.json`** — Primary state file per stream. Read at session start, updated throughout, saved at session end.
|
|
201
|
+
- **`.harness/streams/<name>/learnings.md`** — Append-only knowledge base per stream.
|
|
202
|
+
- **`.harness/streams/<name>/failures.md`** — Active anti-patterns per stream.
|
|
203
|
+
- **`.harness/streams/<name>/handoff.json`** — Structured context from last skill per stream.
|
|
204
|
+
- **`.harness/streams/index.json`** — Stream index tracking known streams, branch associations, and active stream.
|
|
191
205
|
- **`.harness/trace.md`** — Optional reasoning trace. Useful for debugging agent behavior across sessions.
|
|
192
206
|
- **`.harness/archive/`** — Archived failure logs. Check for historical context when encountering recurring issues.
|
|
193
207
|
|