HARBOR DESK / 10 / PRACTICE GUIDE

Security review of AI-generated code

AI can accelerate work; authority over security decisions is retained. Evaluate generated code, package suggestions and self-authored tests with independent evidence.

Download guide and workpapers

Original AI-assisted SecNet educational content; examples are fictional. Not a source organization publication or endorsement. Sources checked: 2026-10-21.

CODE REVIEW DESK

See the decision through the test.

Code here is a local policy model with no target connection. Passing model cases are not security approval or device tests.

The model said it was secure / Weak code

Inspect an incomplete decision based on record existence or another positive signal. Consider denial cases alongside permitted use.

s=>s.modelSaysSecure

The model’s claim is neither server authorization nor a negative test. Require tenant and abuse tests as independent evidence.

Choices and outputs last only on this open page; they do not update account progress, career status, points or certificates.

01 / EXPLANATION

From claims to evidence

A “secure” comment is not a test result. Trace actor origin, tenant boundaries, parameter binding and error paths in generated code. Tests written by the same model may repeat the same implementation assumption. Derive acceptance criteria from the understood business rule first and independently design negative cases. Compare claimed security in comments with actual controls.

02 / EXPLANATION

Package and secret boundaries

A suggested package may not exist or may resemble a maliciously named package. Verify registry, maintainer, version, source and license before installing. Do not send production secrets, real customer records or private code to an unauthorized service. A small synthetic reproduction is often sufficient. Read the privileges and file effects of generated commands before execution.

03 / EXPLANATION

Human review and release

Generative AI does not remove required tests or code-owner review. Preserve traceability among change, model suggestion, independent tests and release approval. If sensitive input reaches an unauthorized service, deleting the message is insufficient; consider credential revocation/rotation and incident handling. The generative-AI profile on the NIST SSDF page is an additional reference; this workshop does not issue compliance evidence.

04 / EXPLANATION

Example review of a generated change

Suppose a model produces a ticket-update function and two green tests. First define expectations independently: owner/tenant stay unchanged, foreign actors cannot write, and stale versions conflict. If the function spreads the entire body into the record, a third case containing owner reveals the flaw despite those green tests. After correction, rerun permitted title updates and tenant separation as well as the original case. Verify the actual source of any suggested package before installation. Record which suggestion was accepted, which assumption failed and which independent evidence changed the decision; model confidence is not evidence.

Build the evidence yourself.

Blank workpapers are not completed tests. Fill them in your authorized environment without secrets or real personal data.

Scope and trust boundariesMarkdown · ENTest plan and expected resultsMarkdown · ENFinding and retest recordMarkdown · ENRelease decision and evidence traceMarkdown · EN
Full guide with code, outputs and reasoning ↓

Primary references

Explanations are authored by SecNet. References support method and platform context; verify current editions and organizational policy for real use.