AfterWard: Autonomous DevSecOps for Life After Code

Inspiration

AI coding assistants can generate applications faster than teams can review, secure, and operate them. Producing code is no longer the only bottleneck. The harder questions begin after the code is written:

• Was the entire repository analyzed, or did the scanner stop early?
• Can an AI agent safely work inside an untrusted repository?
• Did the proposed fix actually stop the original exploit?
• Are security decisions supported by evidence?
• Is the reviewed source commit the same code running in production?
• Will a failed deployment or unhealthy service be detected and recorded?

A generated application may compile and look complete while still containing command injection, exposed credentials, unsafe dependencies, insecure business logic, or incomplete security coverage. Conventional automation can also report an apparently clean result when a scanner crashes, skips files, or produces malformed output.

I originally explored autonomous application defense in my MIT-licensed project, Arbalest. AfterWard develops those ideas into a GitLab-native DevSecOps system centered on GitLab Duo, deterministic security controls, adversarial verification, governed delivery, and production evidence.

The name AfterWard reflects its purpose: it protects everything that happens after software has been generated.

What is AfterWard?

AfterWard is an autonomous DevSecOps agent and security control layer for AI-generated and rapidly developed software.

GitLab Duo provides the reasoning layer that investigates a merge request, understands findings, prepares remediation, and explains the outcome. AfterWard surrounds that reasoning with deterministic controls that scan the source, restrict agent actions, test fixes, enforce policy, preserve evidence, verify deployment identity, and monitor the running service.

AfterWard does not accept an AI-generated statement such as “the vulnerability is fixed” as proof. It requires machine-verifiable evidence before allowing the lifecycle to continue.

The project combines:

• A custom GitLab Duo DevSecOps agent
• A three-component GitLab Duo lifecycle flow
• Seven deterministic Model Context Protocol tools
• A fail-closed agent security harness
• Multi-layer source and dependency analysis
• Isolated adversarial exploit verification
• A unified security policy gate
• Tamper-evident mission evidence
• Immutable, source-bound cloud delivery
• Runtime identity and health monitoring

The problem it solves

Modern development teams can generate and change code quickly, but security and delivery controls often remain fragmented.

A source scanner produces one report. Dependency analysis produces another. An AI assistant suggests a patch without proving it. A CI pipeline builds a mutable image tag. A deployment system launches an artifact without confirming which source revision it contains. Monitoring then operates separately from the original security decision.

This creates a dangerous gap between code generation and operational trust.

AfterWard closes that gap by joining these activities into one governed lifecycle:

Receive → Investigate → Scan → Patch → Verify → Test
        → Govern → Package → Deploy → Monitor

Each stage produces evidence. A later stage cannot silently replace an earlier decision, reuse approval from another source revision, or interpret missing evidence as success.

Who is it useful for?

AfterWard is designed for:

Teams building with AI coding assistants

These teams can retain the speed of AI-assisted development while adding deterministic checks around generated code and agent actions.

Startups and SaaS developers

Small teams often need to ship quickly without maintaining several disconnected security products and manual review processes. AfterWard places scanning, proof, policy, delivery, and monitoring into one GitLab workflow.

Application-security engineers

Security teams receive normalized findings, bounded exceptions, exploit-based remediation evidence, source-coverage information, and an auditable decision trail.

Platform and DevSecOps teams

Platform teams can use AfterWard to enforce a consistent release policy, connect source commits to immutable container images, and verify the identity of the running Cloud Run revision.

Maintainers reviewing untrusted contributions

Repositories, merge requests, generated files, and tool output are treated as untrusted data. The action gateway and prompt-injection defenses reduce the chance that hostile repository content can control the agent.

How the GitLab Duo agent works

AfterWard uses GitLab Duo as its reasoning and remediation layer.

Its lifecycle flow contains three specialized components:

1. Plan and reconnaissance

The first component examines the merge request and changed files, runs repository reconnaissance, identifies the affected attack surface, and prepares a structured security plan.

2. Fix and prove

The second component studies the vulnerable path, writes a focused remediation, and runs the relevant proof-of-concept against both the vulnerable baseline and the corrected implementation.

3. Evidence-backed reporting

The final component evaluates the collected results and posts a clear MERGE-READY or BLOCKED verdict. The report explains the decision instead of presenting an unsupported claim.

Alongside this lifecycle flow, the AfterWard agent exposes seven deterministic MCP tools:

1. scan_repository scans a repository and produces normalized security findings.
2. scan_code_snippet analyzes an individual source snippet.
3. prepare_fix gives Duo bounded, nonce-fenced context for preparing a remediation.
4. verify_fix tests an exploit against the baseline and corrected versions.
5. query_threat_intel retrieves relevant knowledge from AfterWard's local threat memory.
6. detect_injection detects prompt injection and hostile instructions.
7. run_swarm coordinates deeper analysis and records its result in the mission ledger.

This separates responsibilities clearly:

GitLab Duo reasons and repairs. AfterWard constrains, measures, verifies, and records.

The security harness

An AI security agent needs authority to inspect and change code, but unrestricted authority would create another security problem. AfterWard therefore places a deterministic harness around agent activity.

Action Gateway

The Action Gateway evaluates commands and destination paths before execution. It denies command patterns associated with:

• Privilege escalation
• Container escape
• Unapproved network access
• Destructive filesystem operations
• Uncontrolled package installation
• Access to host credentials and sensitive files

The gateway fails closed when a command is empty, malformed, oversized, or outside its allowed boundary.

Prompt-Injection Defense

A repository can contain comments, documentation, generated files, issue text, or test data that attempts to manipulate an AI agent.

AfterWard detects patterns including:

• Instruction overrides
• Role hijacking
• Forged security verdicts
• Fake tool calls
• Data-exfiltration requests
• Attempts to suppress or falsify findings

Untrusted material is wrapped inside nonce-delimited boundaries and explicitly marked as data rather than instructions. Terminal control sequences are removed before content is displayed.

Tamper-evident Mission Ledger

Important actions and verdicts are written to a SHA-256 hash-chained mission ledger. Each record incorporates the previous record's digest.

Changing, deleting, or reordering a historical entry breaks the chain and can be detected during verification. This provides an auditable history of what the agent measured and decided.

Security analysis

AfterWard combines several complementary analysis methods instead of relying on one scanner.

GitLab-native security

The governed pipeline consumes:

• GitLab SAST
• GitLab Secret Detection
• AfterWard SARIF findings

All required reports must exist and be valid before the policy gate can pass.

Deterministic source analysis

AfterWard includes:

• Secret and credential detection
• Python Abstract Syntax Tree sink analysis
• Semgrep integration
• Fifty-seven deterministic security rules
• Coverage across Python, JavaScript, TypeScript, PHP, Go, Ruby, Java, and C#
• Cross-file taint analysis for Python
• Bounded JavaScript and Go taint-analysis subsets
• Prompt-injection detection
• Dependency inventory and optional OSV advisory lookup
• Source-coverage and parser-completeness checks
• SARIF 2.1.0 output

The source inventory is bounded and explicit. Symlinks, unreadable files, oversized files, parser failures, traversal limits, and unsupported dependency formats are reported as coverage gaps.

AfterWard follows a critical rule:

Incomplete is not clean.

If required analysis cannot complete, the scanner returns an operational failure instead of reporting zero findings.

Adversarial proof of remediation

Finding a vulnerability is useful, but claiming that a patch fixed it is insufficient.

AfterWard uses a Strike Sandbox to run the same proof-of-concept against two states:

1. The known-vulnerable baseline must be successfully breached.
2. The corrected version must neutralize the same exploit.

The sandbox uses:

• No network access
• A read-only filesystem
• A non-root user
• Dropped Linux capabilities
• no-new-privileges
• Process, memory, CPU, and file limits
• Temporary isolated storage
• Execution timeouts
• Per-run nonce-bound verdict markers

A successful baseline proves that the test can reproduce the vulnerability. Failure against the corrected version provides focused evidence that the remediation neutralized that exploit.

The possible outcomes include:

• NEUTRALIZED
• BREACHED
• INVALID_EXPLOIT
• INCONCLUSIVE

AfterWard does not claim that one exploit test proves an entire application is secure. It records the exact scope of what was tested.

Fail-closed governance

AfterWard combines its SARIF report with GitLab SAST and GitLab Secret Detection in one deterministic policy gate.

The default release policy requires:

• Zero unresolved critical findings
• Zero unresolved high-severity findings
• Successful completion of every required scanner
• Valid and parseable security reports
• Successful verification and test evidence
• Approval bound to the current source SHA

Unknown severities are treated as high severity. Missing reports, malformed reports, disabled required scanners, incomplete scans, and stale evidence block the release.

Exceptions must be narrow, reviewed, bounded by count, restricted to an exact file and scanner, and assigned an expiration date. Critical findings and exposed secrets cannot be exempted.

Durable workflow control

AfterWard implements a forward-only workflow state machine. It tracks the project, event, source revision, current stage, verification evidence, approvals, retries, and external side effects.

The controller provides:

• Event deduplication
• Idempotent side effects
• Bounded retries
• HMAC-signed callbacks
• Single-use callback nonces
• Approval bound to the current source SHA
• Automatic invalidation when the source changes
• Prevention of backward or out-of-order transitions

A new commit invalidates verification and approval from the previous commit. This prevents stale evidence from authorizing changed code.

Verified cloud delivery

Once the governance gate passes, AfterWard connects the reviewed source to the running service.

The delivery process:

1. Builds the container with the complete source commit SHA.
2. Records that SHA in the image metadata and filesystem.
3. Runs non-root and read-only container checks.
4. Pushes the image using the full source SHA.
5. Generates a CycloneDX software bill of materials.
6. Resolves and deploys an immutable image digest.
7. Creates a unique Cloud Run revision.
8. Routes traffic to that exact revision.
9. Confirms the runtime source SHA and Cloud Run revision.
10. Verifies that MCP authentication remains enforced.

Workload Identity Federation supports cloud authentication without storing long-lived Google service-account keys in GitLab.

The production sandbox is intentionally unavailable inside Cloud Run. Adversarial verification runs on isolated CI runners, while the deployed service exposes the dashboard, health identity, and authenticated MCP interface.

Monitoring and incident evidence

AfterWard continues checking the service after deployment.

The monitor verifies:

• HTTPS availability
• Health-response structure
• Expected source SHA
• Expected Cloud Run revision
• MCP authentication enforcement

Failures are stored in an append-only incident ledger. Repeated failures for the same target and expected revision update the same incident instead of generating endless duplicate incidents. Recovery resolves the existing incident while preserving its history.

The dashboard only displays evidence obtained from configured GitLab pipeline artifacts or an operator-selected evidence directory. Missing evidence is shown as unavailable rather than fabricated.

Security Confidence Index

AfterWard summarizes evidence with a Security Confidence Index:

$$ \mathrm{SCI} = \frac{(E \times I) + M}{R} $$

Where:

• (E) is evidence completeness.
• (I) is evidence integrity.
• (M) is monitoring confidence.
• (R) is residual risk.

The index helps communicate confidence, but it does not override policy. A favorable score cannot authorize a release containing unresolved critical or high-severity findings.

How I built it

AfterWard is primarily written in Python. FastAPI provides the service, dashboard, health interface, and authenticated HTTP MCP transport. The MCP server also supports standard input and output transport for local GitLab Duo integration.

GitLab CI/CD coordinates planning, verification, testing, security analysis, configuration validation, governance, packaging, release preparation, deployment, and monitoring.

The main implementation includes:

• GitLab Duo agent instructions and lifecycle flow
• Seven MCP tools
• A deterministic scanner and SARIF exporter
• Multi-language detection and taint-analysis engines
• The Action Gateway
• Prompt-Injection Defense
• The hash-chained Mission Ledger
• A Docker adversarial-verification harness
• A forward-only workflow controller
• A unified policy gate
• Evidence and incident pipelines
• A FastAPI dashboard
• Google Cloud Run deployment and identity verification

The test suite covers scanner completeness, dependency analysis, source coverage, agent wiring, evidence construction, service security, verification semantics, deployment preflight checks, monitoring, and dashboard behavior.

Challenges I faced

Proving completeness instead of assuming it

The hardest scanning problem was not detecting one more pattern. It was proving that the expected source was actually inspected. I built explicit source inventory, bounded traversal, parser-error reporting, and exit semantics that distinguish findings from operational failure.

Safely handling hostile repository content

An autonomous agent must read files that may contain malicious instructions. I added nonce fencing, injection signatures, terminal sanitization, and the Action Gateway so repository text cannot silently become trusted control input.

Demonstrating that a fix works

A passing test after a patch does not prove that the test could detect the original vulnerability. AfterWard therefore requires the exploit to breach the baseline before accepting its failure against the corrected implementation.

Preserving source-to-runtime identity

Mutable tags can separate a passing pipeline from the artifact eventually deployed. I bound the source SHA into the image, deployed by digest, created a unique Cloud Run revision, and checked both source and revision identity after deployment.

Combining different evidence formats

GitLab security reports, AfterWard SARIF, sandbox results, tests, agent-wiring evidence, deployment metadata, and monitoring records all use different structures. I normalized them into deterministic governance and evidence formats without treating missing inputs as successful results.

Operating within limited GitLab Duo credits

Duo credits were finite during the hackathon, so I preserved genuine historical workflow evidence and made the deterministic security system independently reproducible through CI jobs, tests, artifacts, and the live dashboard. I did not fabricate agent runs after the allocation was exhausted.

What I learned

I learned that autonomous software security requires a separation between reasoning and authority.

An AI agent is valuable for understanding code, planning remediation, writing a focused patch, and explaining results. Deterministic software should decide whether required evidence exists, whether a command is allowed, whether an exploit was neutralized, and whether a release satisfies policy.

I also learned that security evidence must preserve its scope. A scanner result, an exploit test, a passing test suite, and a healthy deployment each answer a different question. Combining them is useful only when the system keeps those meanings explicit.

Most importantly, I learned that trustworthy automation should report uncertainty honestly:

No evidence is not evidence of safety.

What makes AfterWard different

AfterWard is more than a vulnerability scanner or an AI-generated code reviewer. It governs the complete journey from an untrusted repository to a monitored cloud revision.

Its central design principle is:

Duo can reason. AfterWard makes the reasoning safe, testable, enforceable, and auditable.

That allows teams to keep the speed of AI-assisted development while adding the controls needed to trust what happens after the code is written.

Built With

• application-security
• cyclonedx
• devsecops
• docker
• fastapi
• gitlab-ci/cd
• gitlab-duo
• gitlab-duo-agent-platform
• gitlab-sast
• gitlab-secret-detection
• google-artifact-registry
• google-cloud-build
• google-cloud-run
• model-context-protocol
• osv
• policy-as-code
• prompt-injection-defense
• python
• sarif
• sbom
• semgrep
• supply-chain-security
• taint-analysis
• workload-identity-federation