Review scope and evidence labels
This page defines Secure AI-Assisted Development as an engineering methodology for this site. It covers AI coding assistants, code generation, agentic development workflows and human review of AI-produced changes.
Evidence labels used on this page:
- Official guidance — based on public official software or cybersecurity guidance.
- Community security guidance — based on public security community material such as OWASP.
- Author analysis — interpretation for AI-assisted engineering and governance on this site.
- Implementation evidence required — records that must exist before a security claim is credible.
Methodology snapshot
| Field | Value |
|---|---|
| Category | Secure software engineering and AI-assisted development |
| Research type | Methodology |
| Core idea | AI may generate code, but humans and organisations remain responsible for design, security, review and deployment |
| Typical evidence | Requirements, threat notes, code review, test results, dependency review, SBOM, deployment record, rollback path |
| Main risk | Speed without review, generated vulnerabilities, dependency drift, secret leakage, missing ownership |
| Review status | Security guidance referenced; specific toolchains require separate validation |
What Secure AI-Assisted Development means
Secure AI-Assisted Development is the practice of using AI coding tools without abandoning secure engineering discipline. Evidence: Official guidance; Author analysis.
The method assumes that generated code is untrusted until reviewed, tested and integrated into the same evidence trail as human-written code. Evidence: Author analysis; Implementation evidence required.
It applies to interactive coding assistants, generated application prototypes, agentic code changes, AI-created tests, prompt-driven refactors and deployment automation. Evidence: Author analysis.
What it is not
Secure AI-Assisted Development is not:
- accepting generated code because it runs once,
- treating AI output as reviewed code,
- committing secrets into prompts or repositories,
- skipping dependency review,
- skipping threat modelling because the change was generated quickly,
- replacing human accountability with a model name.
Practical control pattern
| Control | Why it matters |
|---|---|
| Scope and requirement capture | Prevents the assistant from inventing hidden requirements. |
| Threat and abuse review | Identifies security impact before code is merged. |
| Dependency and SBOM review | Reduces supply-chain blind spots. |
| Secret handling | Prevents credentials from entering prompts, logs or repositories. |
| Tests and static checks | Turns claims into repeatable evidence. |
| Human code review | Keeps accountability with the engineering organisation. |
| Deployment and rollback evidence | Supports operational accountability. |
Evidence: Official guidance; Community security guidance; Author analysis.
Relationship to existing Research entries
Secure AI-Assisted Development connects to:
- SBOM — generated software still needs dependency and component visibility,
- Zero Trust — generated applications should not assume trusted networks or users,
- AI Governance — organisations need policies and ownership for AI development workflows,
- Audit Evidence — reviews, tests and approvals must be retained,
- AI Transparency — AI-generated or AI-assisted outputs may need disclosure in some contexts.
Further research directions
Future entries may cover AI coding agents, prompt evidence, AI-generated test quality, model-assisted code review and secure deployment gates as separate nodes.