Open-source security for vibe-coded and AI-built software.

VibeSec Guardian is an open-source application-security toolkit for vibe coders, solo developers, startups, and small teams. It combines a repository-aware coding-agent skill that can run verified local scanners with copyable GitHub Actions profiles for continuous scanning.

VibeSec Guardian cannot guarantee that an application is secure. Scanner coverage is incomplete, findings may be wrong, and a clean scan covers only the checks that completed successfully.

The public product name is VibeSec Guardian. For backward compatibility, the repository remains yakovkazinets/VibeSec, the CLI remains vibesec, and existing .vibesec paths, VIBESEC_* configuration keys, stable vibesec.* identifiers, artifact filenames, and installation metadata remain unchanged. Existing VibeSec installations can upgrade without a rename or reinstallation.

The Passive DAST Baseline add-on is deliberately outside the Minimal and Standard profiles. It is manual/scheduled, unauthenticated, passive-only, and limited to an explicitly configured immutable non-root image on an isolated internal Docker network. Review its threat model before enabling it.

The API Security Baseline add-on is also separate and opt-in. It uses a local OpenAPI 3.x contract and an immutable non-root API image on trusted manual/scheduled events, defaults to GET/HEAD/OPTIONS, and never accepts credentials or public targets. Review its threat model.

The bounded API fuzzing add-on is a further explicit opt-in for eligible isolated API targets. It adds deterministic contract, fuzz, injection, and combined modes, retains safe methods by default, uses only reviewed inert payload families, and publishes no raw request/response bodies. VibeSec Guardian itself declares this capability not_applicable. Review the injection-testing rules and threat model.

Authenticated security testing is a bearer-only opt-in for eligible DAST or API targets. The GitHub secret is scoped to the exact scanner step, passed to the fixed scanner launcher over stdin, and excluded from configuration, arguments, reports, diagnostics, and artifacts. Review the dedicated threat model.

VibeSec Guardian was created by a practicing cybersecurity engineer with relevant security certifications, but I do not claim to be a foremost expert in every area of application security. This project was also developed in part through AI-assisted—or “vibe coding”—workflows, supported by technical research, automated testing, and manual review.

AI-assisted development can introduce mistakes, incomplete assumptions, insecure patterns, and subtle implementation defects. VibeSec Guardian should therefore be treated as an opinionated starting point, not as proof that an application is secure or as a substitute for threat modeling, secure design review, penetration testing, or review by qualified security professionals.

Review the code and configuration before using it, validate it against your own environment and risk model, and report anything that appears incorrect or unsafe. Independent review and security-focused contributions are strongly encouraged.

• Complete documentation index
• v1 stability policy, support policy, and generated interface reference
• Five-minute Quick Start
• Minimal versus Standard
• Compatibility matrix
• Configuration reference
• Project capability questionnaire
• Troubleshooting and preflight
• Upgrading
• Consumer distribution, installation verification, and doctor
• Software supply-chain assurance, release signing, provenance, and the release threat model
• Sanitized sample reports
• Security/result model and threat model
• Security validation policy, capability matrix, and self-hosted validation
• Finding intelligence and framework SAST coverage
• Local execution, platform support, and verified extensions
• Multi-agent support, agent contract, and agent installation
• GitHub Actions Node 24 runtime and immutable pin policy
• OpenAPI API Security Baseline
• Bounded API fuzzing and injection-oriented testing
• v1.1.1 release notes

Supplied workflows target GitHub.com and require Actions Runner 2.327.1 or newer on self-hosted runners. Their reviewed JavaScript actions embed Node 24 and use full commit SHAs; Node 20 is end-of-life and unsupported, and no fallback is provided. VibeSec Guardian itself requires no npm or Node application runtime. Node 26 remains a future compatibility target rather than a requirement. See the runtime policy for the separate GHES limitation.

Minimal uses Trivy filesystem, Gitleaks, and actionlint. Standard adds framework-aware VibeSec Guardian-owned Opengrep rules, OSV-Scanner, Syft SBOMs, conditional isolated Checkov, deterministic finding correlation and explainable priority, explicit coverage reporting, and optional trusted-event scanning of an existing immutable image. Original findings and baseline fingerprints remain authoritative. Neither profile builds or executes application code, installs project dependencies, builds Dockerfiles, or applies infrastructure. Separate opt-in add-ons provide passive ZAP DAST and bounded Schemathesis OpenAPI contract testing against explicitly supplied immutable, non-root images.

Preview adoption without changing the application repository:

python3 scripts/init_vibesec.py --profile minimal --target /path/to/application
python3 scripts/init_vibesec.py --profile standard --target /path/to/application

Installing only the AppSec Guardian skill is enough for an immediate managed local scan. Ask:

$appsec-guardian Run the Standard profile against this repository using real scanners. Install the verified tools if missing. Do not remediate anything yet.

The AppSec Guardian skill itself is small, but its managed scanner toolchain is not. Before asking for approval, the skill reports the selected profile and platform, exact tools, cache directory, verified-cache reuse state, conservative storage range, Docker/Checkov implications, download hosts, and privacy behavior. Minimal commonly requires a 100–400 MB cache plus scanner databases. Standard uses a 500 MB–1 GB planning range plus scanner databases and any Checkov image, and may exceed 600 MB depending on platform and tool versions. Downloads stay outside the application repository; verified cached tools are reused and revalidated.

After approval, the skill verifies the consumer runtime pinned by trusted skill metadata, installs or reuses the exact toolchain, runs real scanners, and reports only validated scanner evidence. Installer progress is written to stderr so JSON stdout remains one final machine-readable object. Assessment-only requests install and execute nothing. Installing a profile into GitHub Actions remains a separate action for continuous CI scanning.

The bundled ./vibesec CLI routes scan, init, doctor, verification, upgrade planning, and extension commands through the existing reviewed implementations. Managed Minimal and Standard scanning supports Linux x86_64, macOS arm64, and macOS x86_64. Linux arm64, Windows, and complete-profile containers fail explicitly; auto never silently selects partial or unverified coverage.

./vibesec scan --profile standard --target /path/to/repository --install-tools --json

./vibesec agents renders the same vendor-neutral safety and validation contract for Codex, Claude Code, Gemini CLI, and Kimi Code CLI. Planning is read-only, installation requires --write, existing instruction files are never overwritten, and no agent CLI, cloud API, credential store, model, or telemetry endpoint is invoked.

Extensions are reviewed local sources only: dry-run installation is the default, --write is explicit, installed content is SHA-256 inventoried, permissions are restricted, capabilities are namespaced, and adapters run as subprocesses rather than imports. Review the extension security model before running extension code.

The initializer asks 17 project-capability questions, each displayed with [Y/n] and defaulting to Yes. Answer No when a capability does not apply. Non-interactive use requires --capabilities-file <trusted-local-json> or the explicit --all-capabilities option; EOF never supplies defaults. The resulting .vibesec/project-capabilities.json is authoritative for scanner applicability. When authenticated testing is enabled, supply only --auth-secret-name; never supply the token.

Add --write only after reviewing the machine-readable plan. Minimal is one stage. Standard deliberately requires support files to land on the default branch before --stage workflow is initialized in a second change, preserving the base-revision trusted-harness boundary. Existing-file conflicts are never overwritten.

For offline distribution, build and verify a deterministic consumer ZIP, then pass it to the initializer with --bundle. The manual official release-candidate path adds strict manifests, checksums, release readiness, signed checksum metadata, SBOM identity, and SLSA-aligned provenance outside the reproducible ZIP. Verify those files with a separately trusted copy of scripts/verify_release_artifacts.py; never bootstrap trust by executing an unverified downloaded script. Check installed support with scripts/verify_installation.py, diagnose it offline with scripts/vibesec_doctor.py, and compare it to a newer verified bundle with the read-only scripts/plan_vibesec_upgrade.py. Local development bundles remain unsigned; signature validity proves identity and integrity, not application security.

Both profiles start in observe; findings are visible while tool/parser failures still fail closed. After review, populate only the matching profile baseline and move to new. Manual adopters can use config/adoption-files.json as the authoritative file list and copy the matching workflow byte-for-byte; preserve executable modes and never interchange baselines.

Fork pull requests receive no secrets or registry credentials. Raw scanner output is not uploaded. Standard OSV online mode may send package metadata and file hashes; SBOMs may disclose internal package names/versions. Read the Quick Start before enabling it in a private repository.

python3 -m unittest discover -s tests -v
scripts/install_tools.sh . .tools/bin
VIBESEC_ENFORCEMENT=observe scripts/run_minimal_profile.sh . results
scripts/install_standard_tools.sh . .tools/bin
VIBESEC_ENFORCEMENT=observe python3 scripts/run_standard_profile.py . results

Read the architecture, tool selection, threat model, and contribution guide before changing security-sensitive behavior.

Every advertised capability must have maintained positive and negative fixtures, controlled failure evidence, artifact validation, and mandatory CI enforcement. Fixture guidance and self-scan expectations are documented in self-hosted validation.

Imported skills can be structurally checked with python3 scripts/validate_skill.py path/to/skill after installing requirements.txt. See imported skill validation. Validation does not execute or grant authority to imported instructions.

Licensed under Apache-2.0. See LICENSE.