Governance in Spec-Driven Development

Jeriel Juarbe — Wed, 22 Jul 2026 15:31:21 +0000

A reproducible GCP example using GitHub Spec Kit, SicarioSpec, Terraform, Checkov, and Conftest to turn AI-assisted intent into enforceable policy and evidence.

AI coding agents can generate infrastructure quickly. They cannot infer an
organization's authoritative risk decisions from a seven-word request.

Consider this prompt:

Create a GCP bucket for customer documents.

That is enough to produce Terraform. It is not enough to decide:

How the data is classified
Which regions and retention periods are allowed
Whether public access or object ACLs are prohibited
Which workload identities may access the bucket
Whether CI may use long-lived credentials
Which logs, labels, tests, and evidence are required
Who may approve a plan or run terraform apply

Seven words create direction—not an infrastructure specification.

This post walks through a reproducible example using
GitHub Spec Kit,
SicarioSpec, Terraform,
Checkov, and OPA/Conftest. The objective is not to claim that automated gates
make infrastructure secure. It is to show how a specification can make
security obligations explicit, testable, and capable of stopping delivery.

Why the specification matters

A common AI-assisted workflow looks like this:

prompt -> generated code -> review -> patch the missing decisions

Spec-Driven Development (SDD) moves the decisions earlier:

principles -> specification -> clarification -> plan -> tasks
           -> implementation -> validation

GitHub Spec Kit provides the workflow structure:

A constitution for durable project principles
A specification for the intended behavior and outcome
A plan for architecture and technology decisions
A task list for executable work
Analysis and validation against the declared intent

Spec Kit also provides extension points through presets, extensions, and
bundles. SicarioSpec is an independent, community-authored governance bundle
for that ecosystem. It adds governed artifact templates, threat and risk
workflows, data classification, evidence requirements, policy-as-code
starters, CI integration, control maps, and companion CLI verification.

The core distinction is simple:

A specification that mentions security is not necessarily governed. A
governed specification makes security obligations explicit, traceable,
testable, and enforceable.

Turning the request into a security contract

I initialized the demonstration with the cloud infrastructure, security
toolchain, and compliance profiles:

sicario init gcp-customer-documents \
  --integration all \
  --profile cloud-iac,security-toolchain,compliance \
  --frameworks ccm

The selected CSA CCM map is an illustrative traceability surface. Selecting a
control map does not claim certification, legal applicability, or that every
control is satisfied.

The feature specification required:

Confidential data classification
Explicit residency and retention decisions
public_access_prevention = "enforced"
Uniform bucket-level access instead of object ACLs
A dedicated service account with bucket-scoped object access
Workload identity federation for CI
No service-account keys
Required governance labels
Terraform, Checkov, Conftest, and SicarioSpec evidence
Named human approval before any plan is applied
No automatic or agent-authorized terraform apply

The specification becomes a security contract: classify, constrain, test, and approve.

The requirements reflect separate control layers. Google recommends
uniform bucket-level access
for a unified IAM model and documents
public access prevention
as a separate control against public principals. For CI,
workload identity federation
avoids the operational and security burden of service-account keys.

Negative tests: valid syntax, unacceptable policy

I created an unsafe Terraform-plan fixture before accepting the corrected
infrastructure. The fixture deliberately:

Used US-EAST1, which was not an approved region
Left public access prevention as inherited
Disabled uniform bucket-level access
Omitted the required labels
Granted roles/storage.objectViewer to allUsers
Created a long-lived service-account key

Terraform validation passed. That is expected: provider-schema validation does
not answer whether a configuration satisfies organization-specific security
policy.

The custom Conftest policy produced six failures:

FAIL service-account key is prohibited
FAIL required governance labels are missing
FAIL uniform bucket-level access must be enabled
FAIL public access prevention must be enforced
FAIL region US-EAST1 is not approved
FAIL bucket IAM grants access to allUsers

7 tests · 1 passed · 6 failed

Checkov independently identified five unsafe conditions: missing public-access
prevention, versioning, access logging, uniform bucket-level access, and
protection against anonymous access.

Syntax validation asks “can this run?” Policy asks “are we willing to run it?”

These results came from containerized executions against committed fixtures.
They are not hand-written example output.

Remediating the Terraform

The corrected bucket configuration included the controls required by the
specification:

resource "google_storage_bucket" "customer_documents" {
  location = "us-central1"

  uniform_bucket_level_access = true
  public_access_prevention    = "enforced"

  versioning {
    enabled = true
  }

  logging {
    log_bucket = var.audit_log_bucket
  }

  labels = local.required_labels
}

The application service account receives only bucket-scoped
roles/storage.objectUser. The Terraform contains no service-account key
resource.

The first corrected Checkov execution still identified missing Cloud Storage
access logging. I added log delivery to a separately governed audit bucket and
reran the complete stack. This is an important benefit of layered checks: the
custom policy enforced the declared organization-specific contract while
Checkov supplied a broader known-misconfiguration check.

Governance changed both the Terraform and the authority model around it.

The corrected gate stack

The final results were:

Terraform validate    configuration valid
Checkov               6 passed · 0 failed
Conftest              7 passed · 0 failed
SicarioSpec           governance contract passed

The tools are complementary rather than interchangeable:

Layer	Question answered
Spec Kit artifacts	Did we record intended behavior, architecture, and work?
`sicario verify`	Is the required governance and evidence contract complete?
Terraform validation	Is the provider configuration valid?
Checkov	Does the IaC contain known security misconfigurations?
OPA / Conftest	Does the plan meet organization-specific GCP policy?
Human plan review	Is this the intended change, and is the residual risk acceptable?
GCP IAM and Organization Policy	Can the platform enforce the deployed boundary?

The demonstration used no GCP credentials and ran no terraform apply.
Passing automated gates made the change ready for human plan review. They did
not authorize a deployment.

Green gates establish readiness for review—not permission to deploy.

Contributing the bundle upstream

SicarioSpec is not only a preset collection. I built the distribution as a
versioned Spec Kit bundle containing the presets, an extension, governed
artifact templates, security and policy-as-code workflow starters, control
maps, and companion CLI verification. The goal is to make the integrated
governance system installable and repeatable rather than asking adopters to
assemble each component independently.

This is a personal community contribution developed during my weekend time. I
started it as part of a broader effort to improve my skills and become more
effective at producing useful outputs rapidly without sacrificing structured
governance. In my recent learning journey, I have also been using these ideas
to build and test workflows for malware analysis and reverse engineering.
Those use cases make evidence provenance, repeatability, and human authority
especially concrete.

The SicarioSpec bundle submission to GitHub Spec-Kit is now complete, accepted, and merged into the upstream path. Available now!

A practical authority model for AI-assisted delivery

The resulting authority chain is:

AI or developer proposes
        ↓
non-AI tools validate
        ↓
humans approve material impact
        ↓
the cloud platform enforces deployed policy

Or, stated as an operating model:

Development owns the change. Security defines the guardrails. Code enforces
the minimum contract. Humans approve material risk.

This does not require every team to adopt every possible governance artifact.
A practical starting point is one repository and one meaningful feature:

Establish project principles before feature-level implementation.
Classify data and identify trust boundaries before selecting architecture.
Convert security requirements and abuse cases into tasks and negative tests.
Run governance verification before implementation and again before release.
Require structured, time-bound exceptions instead of silent bypasses.
Tune the baseline using findings from real features.

What deterministic verification does not prove

A passing sicario verify result does not prove that software is secure. It
does not grant compliance approval or certification. Templates do not replace
expert analysis, and an AI-generated threat model is not authoritative simply
because it is detailed.

“Deterministic” applies to the gate's verdict: non-AI code reads repository
artifacts and applies fixed rules. It does not make AI output deterministic or
automatically correct.

Human judgment remains necessary for architecture, legal applicability,
production readiness, security exceptions, and accepted risk.

What a deterministic gate can prove is narrower and useful: the declared
repository contract was evaluated consistently, required artifacts were
present, and known omissions could stop delivery instead of becoming forgotten
advice.

The larger point

AI has made producing code cheaper. It has not made explaining, governing, and
accepting the risk of that code cheaper.

If specifications become executable inputs to delivery, security and
governance should become first-class parts of those specifications. The goal is
not more paperwork. The goal is to make the secure path the normal path and
preserve evidence of the decisions that got us there.

Explore the projects:

The real question is simple: why wouldn’t we make Spec-Driven Development with
SicarioSpec the standard for AI-assisted delivery?

DEV Community: Jeriel Juarbe