chore: add kiro spec-driven tooling and steering docs

Add the Kiro-style agentic SDLC tooling used to drive this project: the
.opencode/skills/kiro-* skill set (discovery, spec init/requirements/design/
tasks, validation, implementation, review, steering), the .kiro/settings
templates, and AGENTS.md describing the workflow. Update the spec docs
(assessment/design/requirements/tasks) to current state.

Scope tests/test_opencode_skills.py to the project's own openultrasast-*
skills so the third-party kiro-* tooling (which uses a different frontmatter
convention) no longer breaks the frontmatter check.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
This commit is contained in:
Marius Ciepluch
2026-06-21 14:28:19 +02:00
co-authored by Claude Opus 4.8
parent 8fe8911020
commit 6699f1f8f9
58 changed files with 5509 additions and 2 deletions
@@ -34,6 +34,15 @@ The first release should support this workflow:
ousast scan /path/to/repo --mode quick
```
The first realistic quality milestone should add benchmark-grounded evaluation before claiming language coverage:
```text
ousast benchmark benchmarks/javascript-node.toml --mode standard
ousast benchmark benchmarks/python-web.toml --mode standard
ousast benchmark benchmarks/java-web.toml --mode standard
ousast benchmark benchmarks/c-cpp.toml --mode quick
```
It should produce:
```text
@@ -50,6 +59,12 @@ The key product promise should be:
OpenUltraSAST tells you where security review should start, what it suspects, what evidence exists, what evidence is missing, and which findings have survived independent verification.
```
For coder education, the complementary promise should be:
```text
OpenUltraSAST explains why the pattern is dangerous, what evidence proves or weakens the finding, how to fix it safely, and how to avoid recreating the same bug class.
```
## Core Architecture Recommendation
Use a Python implementation initially. Clearwing and HarnessX are both Python, Docker and SARIF libraries are mature, and Trail of Bits tooling integration will be simpler. OpenCode integration can happen through MCP and command files rather than requiring the core scanner to be TypeScript.
@@ -149,6 +164,8 @@ Examples:
False-positive elimination should be handled the same way: a model can recommend demotion or suppression, but the harness should require a scoped reason and counter-evidence.
Benchmark grounding should be handled with the same discipline. A scanner that passes tiny fixtures but misses NodeGoat, PyGoat, OWASP Benchmark/WebGoat, Juliet, or small sanitizer-backed parser targets is not a realistic finder. Language support should be claimed only after benchmark runs show useful recall and auditable false-positive behavior on realistic vulnerable projects.
False-positive reasons should include:
- No attacker-controlled path.