drogonsec is an open-source security scanner that combines SAST, SCA, secret detection and IaC checks with optional local AI remediation, built for authorized DevSecOps workflows on codebases you own.
| Tool | filipi86/drogonsec — Go-based open-source scanner combining SAST, SCA, secret detection, IaC checks and AI remediation |
| Category | Application security testing / code and dependency scanning |
| Primary Use | Scanning your own repositories for injection flaws, vulnerable transitive dependencies, leaked secrets and Terraform/Kubernetes misconfigurations, with SARIF and CycloneDX output for CI integration |
| Safe Use | For authorized security assessments, internal development pipelines and defensive research on codebases you own or are contracted to test; the scanner is entirely defensive and runs offline |
| Telemetry Note | Purely local: no network calls during dependency resolution, findings written to 0600-permission reports, AI cache under ~/.drogonsec/ — defenders observe it as routine CI activity producing SARIF uploads |
drogonsec positions itself as a single-binary answer to a question most teams currently answer with three or four tools: is this codebase vulnerable, are its dependencies vulnerable, and did anyone commit a credential. Written in Go and installed via go install github.com/filipi86/drogonsec/cmd/drogonsec@latest, it bundles four engines — SAST across 20+ languages, SCA, secret detection the project calls Leaks, and IaC misconfiguration checks for Terraform, Kubernetes and Nginx — plus an optional AI remediation layer. At roughly 183 stars it is a young project, but the README reads like a design document rather than a marketing page, and the v0.4.0 SCA rework in particular shows serious engineering thought.
The headline capability in v0.4.0 is what the project calls full-depth SCA. Most composition scanners read manifests, which declare a handful of direct dependencies at version ranges; the code you actually ship is the resolved lockfile tree, and that is where nearly all advisories live. drogonsec reads lockfiles and installed trees for npm, Yarn, Python, PHP, Rust and Ruby, the package manager's own cache for Go and Dart, and resolves Maven offline against ~/.m2 using Maven's own rules — parent POMs, imported BOMs, nearest-wins, dependency management, exclusions — claiming artifact-for-artifact parity with mvn dependency:tree. The gradle.lockfile is also parsed.
The offline Maven resolution is the most technically ambitious part. Rather than hitting a registry, the engine reconstructs the dependency graph from the local repository that already exists after a build, which means a scan works air-gapped and answers what shipped rather than what would install today. The README is explicit about the philosophy: resolving a range against a registry answers a different question. The tradeoff is stated honestly too — a manifest-pinned range like lodash: "^4.17.15" is not checked against advisories because reporting findings for 4.17.15 would name a version you never installed; those packages still land in the inventory and SBOM, and the scan reports how many it skipped. The fix, the project argues, is committing a lockfile.
Every SCA finding carries provenance: whether the package is direct and the route that introduced it, so a developer sees Required : via guzzlehttp/guzzle and knows which dependency to actually change. That dependency-path context is what separates a scanner developers act on from one they ignore, and it flows into the CycloneDX 1.5 export, which includes the full dependencies graph — every edge — for consumption by Grype, Trivy or Dependency-Track. v0.4.0 also stabilizes fingerprints so findings keep their identity across scans and code moves, exposed both in JSON and as SARIF partialFingerprints.
The SAST engine covers the expected language spread — Python, Java, JavaScript, TypeScript, Go, Kotlin, C#, PHP, Ruby, Swift, Dart, Elixir, Erlang, Shell, C/C++ and more — and maps findings to OWASP Top 10:2025 categories, CWE identifiers and CVSS 3.1 scores. Notably the project claims coverage of all ten 2025 categories including the two new ones, Supply Chain and Mishandling Exceptions, which is a signal the rule set was written against the current list rather than recycled from the 2021 edition. Sample output shows the expected shape: rule ID, file and line, OWASP mapping, CWE, score and a short fix hint.
The Leaks engine ships 50+ secret patterns covering AWS, GCP, GitHub, JWT and SSH keys, with a configurable min_entropy threshold in .drogonsec.yaml and a --git-history flag that sweeps commit history rather than just the working tree. That history scan matters for the common failure mode where a credential was committed, deleted a commit later, and still lives in every clone. The configuration file also lets teams tune workers, ignore_paths, per-engine enablement and fail_on severity gates — the pieces you need to wire the tool into a pipeline without drowning developers in noise.
Output flexibility is clearly a design goal. Beyond the default text report, drogonsec scan . --format json and --format html cover human and machine consumers, --format sarif plugs into GitHub Advanced Security via github/codeql-action/upload-sarif@v4, and --format cyclonedx produces the SBOM described above. An SPDX export is planned but not yet present. The --severity HIGH flag filters to high and critical, and --no-sca, --no-leaks, --no-sast let you run engines selectively when triaging.
The AI remediation layer is the most distinctive feature. With Ollama and DeepSeek Coder as the recommended local option, drogonsec scan . --enable-ai auto-detects a local model server and generates context-aware fixes with no data leaving the machine — a meaningful posture for security teams that cannot paste source into a cloud API. Cloud providers (anthropic, any OpenAI-compatible endpoint via --ai-provider custom) are supported with AI_API_KEY, and the config offers high_severity_only to ration tokens.
What deserves real credit is the hardening the AI client received, documented in docs/security.md. The client refuses 3xx redirects so an x-api-key cannot leak to a third-party host through a 302 Location; it enforces HTTPS for non-loopback endpoints; every cached AI response is tagged with an HMAC-SHA256 integrity key stored 0600 under ~/.drogonsec/ai-cache/; Ollama auto-detection validates the actual /api/tags response shape rather than trusting an open port; and all cached files and --output reports are written 0600 because they embed code snippets and secrets. This is threat-model-driven engineering — the authors clearly asked what an attacker could do with an AI hook into a security tool.
Practical caveats before adopting: the repository metadata reports License: NOASSERTION even though the README badge claims Apache 2.0, so legal review should confirm the actual LICENSE file before commercial deployment. Documentation lives partly off-repo at the project's own site, and the Docker path via ghcr.io/filipi86/drogonsec is the cleanest way to run scans without polluting a host with Go toolchain requirements. For an authorized DevSecOps pipeline, internal security reviews, or defensive research on your own code, drogonsec offers an unusually coherent combination of depth-first dependency analysis, standard-format reporting and privacy-preserving remediation — the v0.4.0 SCA work alone makes it worth a trial scan against a project with a known messy dependency tree.
filipi86/drogonsec.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.