If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/greenbone/openvas-scanner shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1d ago
• 7 active contributors
• Distributed ownership (top contributor 29% of recent commits)
• GPL-2.0 licensed
• CI configured
• Tests present
• ⚠ GPL-2.0 is copyleft — check downstream compatibility

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live greenbone/openvas-scanner repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/greenbone/openvas-scanner.

What it runs against: a local clone of greenbone/openvas-scanner — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in greenbone/openvas-scanner | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of greenbone/openvas-scanner. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/greenbone/openvas-scanner.git
#   cd openvas-scanner
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of greenbone/openvas-scanner and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "greenbone/openvas-scanner(\\.git)?\\b" \\
  && ok "origin remote is greenbone/openvas-scanner" \\
  || miss "origin remote is not greenbone/openvas-scanner (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-2.0" \\
  || miss "license drift — was GPL-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/greenbone/openvas-scanner"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

OpenVAS Scanner is the core vulnerability assessment engine for Greenbone Community Edition that executes continuously-updated Vulnerability Tests (VTs) written in NASL to scan systems for security flaws. It's a dual-stack project with a legacy C/NASL implementation (~1.5M lines of C) and an emerging Rust replacement (~2.3M lines) aiming to unify the scanner, ospd-openvas, and notus-scanner into a single simplified binary. Hybrid monorepo: the legacy C implementation lives in the root with CMake build (INSTALL.md, CMakeLists.txt implied), NASL script engine, and daemon logic; the emerging Rust project is isolated under rust/ with its own Cargo.toml (per rust/README.md reference). CI/CD is centralized in .github/workflows/ with separate build pipelines for Rust (build-rs.yaml) and C (build.yml). Docker multi-stage builds in .docker/prod.Dockerfile containerize both stacks.

Security teams and Greenbone Enterprise users who need to perform vulnerability scans at scale; Greenbone developers and contributors maintaining the core scan engine; DevSecOps engineers integrating OpenVAS into containerized environments (per the .docker/ production Dockerfile and Greenbone Community Containers docs).

Production-ready and actively maintained. The project has multiple stable releases on GitHub with signed artifacts, comprehensive CI/CD pipelines (.github/workflows/ with tests.yml, build.yml, functional.yaml, codeql.yml), Docker Hub distribution (100k+ pulls), and is part of an enterprise appliance. The Rust rewrite is actively in progress but the C implementation is battle-tested.

Standard open source risks apply.

Active dual-track development: the Rust rewrite in rust/ is progressing (separate build pipeline build-rs.yaml), while the C scanner remains the active scan engine. Recent work includes Helm chart releases (.github/workflows/helm-release-on-tag.yml), package distribution on multiple Debian variants (.docker/packages/), and functional test expansion (.github/workflows/functional.yaml). DevContainer setup (.devcontainer/) indicates increased focus on contributor experience.

git clone https://github.com/greenbone/openvas-scanner.git && cd openvas-scanner && cmake . && make install (per INSTALL.md). For Rust development: cd rust && cargo build. For Docker: docker build -t openvas-scanner -f .docker/prod.Dockerfile . For dev environment: use the provided .devcontainer/ with .devcontainer/Makefile for automated setup.

Daily commands: C/legacy: cmake . && make && openvas (daemon, requires gvm-libs setup per .github/install-openvas-dependencies.sh). Rust: cd rust && cargo run --release. Docker: docker run ghcr.io/greenbone/openvas-scanner:stable. DevContainer: open in VSCode with Remote-Containers extension (auto-configured in .devcontainer/devcontainer.json).

• INSTALL.md: Canonical installation and build instructions including gvm-libs dependency setup
• .devcontainer/devcontainer.json: Defines reproducible dev environment with all dependencies (gvm-libs, Rust, C toolchain) for onboarding
• .docker/prod.Dockerfile: Production containerization strategy showing both C and Rust components in final image
• rust/README.md: Entry point for understanding the Rust rewrite project goals and current status
• .github/workflows/build-rs.yaml: Rust CI/CD pipeline showing how the new implementation is tested and distributed
• .github/workflows/functional.yaml: End-to-end scanning tests that validate vulnerability detection across VT scripts
• .clang-format: C code style requirements for legacy codebase contributions
• .github/install-openvas-dependencies.sh: Explicit list of external C library dependencies (gvm-libs, GPGME, Redis client, etc.)

VT script logic → nasl/ directory (NASL syntax); scanner core → C source files (see .clang-format for style); Rust migration code → rust/ with separate Cargo.toml; CI/CD changes → .github/workflows/ YAML files; containerization → .docker/prod.Dockerfile and .docker/railguards/ for hardened variants; build config → CMakeLists.txt (C) or Cargo.toml (Rust).

1. gvm-libs is an external dependency not in this repo (.devcontainer/build-gvm-libs shows custom build step); installation via INSTALL.md is mandatory. 2) NASL interpreter requires compiled NASL files; raw .nasl scripts won't execute without proper loading from the VT feed. 3) The scanner expects to run as a daemon with specific permissions and network access; .github/install-openvas-dependencies.sh shows required system packages. 4) Rust rewrite currently still uses C openvas-scanner as scan engine (per README 'currently it uses the openvas-scanner as scan engine'), so full replacement is incomplete. 5) Redis dependency implied for caching/state management in production deployments (not explicit in file list but common in GVM stack).

• NASL (Nessus Attack Scripting Language) — 460K LOC in this repo is NASL; understanding the VT script format is essential for contributing vulnerability tests and debugging scan results
• NVT Feed Distribution & Signing — Greenbone Community Feed integrity is critical; GPG signing verification (.github/sign-assets.sh) and continuous feed updates drive the scanning capability
• Daemon Process Architecture — openvas-scanner runs as a long-lived daemon handling concurrent VT execution; understanding signal handling, resource limits, and multi-process VT isolation is required for core modifications
• CMake Cross-Platform Build System — The legacy C implementation uses CMake for compilation targeting Linux/Debian variants; INSTALL.md and .devcontainer/ show this is the canonical build method
• OSP (OpenVAS Scanner Protocol) — Scanner communicates with ospd-openvas wrapper via OSP; understanding this protocol is necessary for scanner integration and testing
• Vulnerability Test Orchestration & Result Reporting — VTs execute in sequence/parallel against target hosts; the scanner aggregates results into vulnerability reports; understanding VT lifecycle is core to scanner logic
• Containerized Vulnerability Scanning Distribution — The .docker/ and Helm chart deployment model shows scanner is designed for scale via container orchestration; multi-architecture builds and resource constraints matter

• greenbone/gvm-libs — Core C library dependency providing GVM protocol, NVT database, and crypto primitives that openvas-scanner links against
• greenbone/ospd-openvas — Legacy OSP daemon wrapper around openvas-scanner; being replaced by the Rust rewrite to unify the stack
• greenbone/notus-scanner — Stateless vulnerability scanner that the Rust rewrite aims to merge alongside openvas-scanner functionality
• greenbone/openvas-plugins — Repository of NASL Vulnerability Tests (VTs) that openvas-scanner executes; continuously updated feed
• greenbone/greenbone-community-containers — Orchestration layer using openvas-scanner Docker images for complete Greenbone Community Edition deployment

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for .devcontainer build scripts

The .devcontainer/ directory contains critical setup scripts (build-cmake-project.sh, build-gvm-libs, build-openvas, prepare-user-dirs.sh) but there's no visible test coverage or CI workflow validating they work correctly. A new GitHub Actions workflow could test the devcontainer builds on pull requests to catch regressions early, especially important since contributors depend on these scripts.

• [ ] Create .github/workflows/test-devcontainer.yml that builds the devcontainer on PRs
• [ ] Add tests for .devcontainer/build-gvm-libs and .devcontainer/build-openvas scripts to verify they exit cleanly
• [ ] Document expected environment variables and failure modes in .devcontainer/README.md (if missing)

Create a railguards test workflow to validate Dockerfile builds

The .docker/railguards/ directory contains Dockerfiles for debian_bookworm.Dockerfile and debian_stable.Dockerfile but there's no visible CI workflow testing them. These are security-critical infrastructure images. Adding a workflow would catch build failures and security issues before they reach production.

• [ ] Create .github/workflows/test-railguards.yml to build both .docker/railguards/debian_*.Dockerfile on each PR
• [ ] Add hadolint or similar Docker linting to the workflow per .docker/railguards/README.md requirements
• [ ] Document the purpose and maintenance cycle of railguards in .docker/railguards/README.md

Implement dependency-check integration for supply chain security

The repo has .github/workflows/dependency-review.yml but no dedicated workflow for scanning dependencies (like OWASP Dependency-Check or cargo-audit for Rust components). Given OpenVAS is a security scanner itself, implementing comprehensive dependency vulnerability scanning would improve supply chain security and set an example for the security community.

• [ ] Add .github/workflows/dependency-scan.yml to run cargo-audit on Rust code (based on .github/actions/setup-rust/action.yml)
• [ ] Add OWASP Dependency-Check or Snyk scanning for C/CMake dependencies referenced in CMakeLists.txt
• [ ] Document the dependency update policy and vulnerability response process in a new SECURITY.md file

• Add missing unit tests for the Rust wrapper layer in rust/src/ to increase code coverage beyond the legacy C implementation
• Document the NASL VT script API contract in a structured format (e.g. markdown spec) since .nasl files exist but no developer guide for writing custom VTs is visible in the file list
• Expand functional.yaml CI workflow with additional .hurl test scenarios for edge cases (empty host lists, malformed NASL scripts, network timeout handling) since only 8K lines of .hurl files exist

The OpenVAS Scanner repository demonstrates reasonable security practices with CI/CD workflows and containerization, but has several gaps: (1) No container image security scanning visible in the build pipeline, (2) Insufficient dependency management visibility for analysis, (3) Missing formal vulnerability disclosure policy, (4) No evidence of SBOM signing/verification. The codebase appears well-structured with security tooling (CodeQL, linting, formatting checks), but should strengthen supply chain security controls and add explicit container scanning to prevent deployment of vulnerable images. No hardcoded credentials or obvious injection vulnerabilities detected from file structure alone, but runtime analysis would be needed for thorough assessment.

• Medium · Missing SBOM Signing Verification — .github/workflows/sbom-upload.yml. The repository includes SBOM upload workflow (.github/workflows/sbom-upload.yml) but there is no evidence of signature verification for Software Bill of Materials. This could allow tampering with SBOM data. Fix: Implement cryptographic signing and verification of SBOM artifacts. Use tools like Cosign or similar to sign SBOMs and verify signatures during CI/CD pipeline.
• Medium · Docker Image Build Without Security Scanning — .docker/prod.Dockerfile, .docker/railguards/. Multiple Dockerfile variants exist (prod.Dockerfile, railguards dockerfiles) but no evidence of container image scanning in CI/CD pipeline. This could allow vulnerable base images or dependencies to be deployed. Fix: Implement container image scanning in CI/CD workflows using tools like Trivy, Grype, or Snyk. Fail builds if critical vulnerabilities are detected.
• Medium · Incomplete Dependency Management Visibility — .docker/packages/. Package dependency files referenced in .docker/packages/ (latest.txt, oldstable.txt, testing-edge.txt) are listed but content not provided for analysis. This makes it difficult to identify vulnerable dependencies. Fix: Provide explicit dependency pinning with version constraints. Use dependency scanning tools in CI/CD to detect known vulnerabilities. Implement regular dependency updates.
• Low · Missing Security.txt File — Repository root. No security.txt or SECURITY.md file found in the repository for vulnerability disclosure policies. This makes it unclear how security researchers should report vulnerabilities. Fix: Create a SECURITY.md file documenting vulnerability disclosure process and contact information as per RFC 9110.
• Low · Codecov Integration without Configuration Review — .codecov.yml. Code coverage tracking (.codecov.yml) is present but security implications of coverage token exposure are unclear. Fix: Ensure codecov tokens are managed as secrets in CI/CD. Review codecov configuration for public repository exposure of sensitive metrics.
• Low · Development Container Potential Security Exposure — .devcontainer/Dockerfile, .devcontainer/devcontainer.json. Development container configuration (.devcontainer/) may expose elevated permissions or insecure defaults that shouldn't be used in production. Fix: Ensure development container configurations are clearly separated from production. Review for unnecessary elevated privileges (--privileged, root user).

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.