Vulnenv week11

[Nayeraneru]

Refering to rapid7#20506
GSoC 2026 — Week 11 deliverables for the Automated Vulnerable Environment Provisioning project.

Summary
Integrates test_env into GitHub Actions, replacing static container definitions with environment-driven provisioning. The CI matrix consumes the same YAML definitions as local users, validating that shared definitions, health checks, datastore automation, and exploit execution work identically across local dev and CI.

Changes

• .github/workflows/test_env.yml: CI matrix testing 7 reference modules (3 exploits, 4 auxiliaries) across 4 shared definitions.
• scripts/ci_runner.sh: Headless wrapper that runs build → exec -z → validate → remove-all and exits 0 on PASS, 1 on FAIL.
• test_env exec -z: New --background flag for non-interactive automation; defaults unchanged for interactive users.
• ci.exploit.force_exploit: New YAML schema field; set in activemq.yml broker-only profile to bypass the OpenWire liveness/readiness race.
• TCP grace period: 5-second pause after TCP health checks to allow protocol initialization before exploitation.
• Artifact upload: Collects msfconsole logs on every run (if: always()) for post-failure debugging.
• 7/7 CI jobs passing across shared definitions, HTTP/TCP health checks, provision+verify, and datastore auto-config.

[h00die]

This is so cool!

I noticed for the aux scanners it shows "does not require a session" for the PASS condition, but where did it actually determine what condition had to be present for that module to be considered a pass?

[Nayeraneru]

This is so cool!

I noticed for the aux scanners it shows "does not require a session" for the PASS condition, but where did it actually determine what condition had to be present for that module to be considered a pass?

expected_session: false is just a smoke test right now; it doesn't validate that the scanner actually produced meaningful output

I was thinking about to make validate re-run the environment's health check after auxiliary execution. that proves the module ran without crashing and the service is still responding correctly
although service health is necessary but insufficient, a scanner can fail silently while the target stays up
so I see replacing it with a direct service probe: for auxiliary modules, validate connects to the provisioned target and checks that the live response contains ci.validation.expected_output. this validates actual behavior (Apache banner, SSH handshake), not just side effects