DarkMoon everywhere: pentesting in your IDE, CI/CD, automation and SecOps

Offensive security usually lives in its own silo: a console someone opens on a Tuesday, a PDF that lands in an inbox two weeks later. That is a poor fit for how software actually ships. A developer wants the finding next to the code, a platform team wants the gate in the pipeline, an automation team wants a webhook, and a SOC wants the metric on a board it already watches. So we put DarkMoon where those teams already are. This release note is a tour of the surfaces DarkMoon now plugs into, and an honest map of which capabilities are the open-source engine and which are the paid Pro tier.

The approach: one engine, many surfaces, one privacy posture

Every integration is a thin adapter over the same DarkMoon engine, not a fork of it. Each one runs in one of two modes and auto-detects which is available: an open-source path that speaks to the local engine through the darkmoon.sh / darkmoon-ci CLI over a bind-mounted data and reports directory, and a Pro path that speaks to the REST API at {baseUrl}/api/v1 with a bearer token. When no Pro backend is reachable, an integration degrades to the OSS/local path rather than failing. The engine underneath is the same in both cases: a pentest orchestrator that fingerprints the target and dispatches 50 specialist agents across 142 security tools held behind a single build-enforced allow-list.

CI/CD: gate the build, attach the proof

Three surfaces run DarkMoon inside a pipeline, so a build can be gated on findings and the run carries its own report.

• GitHub Action. Add it to a workflow with uses: ASCIT31/darkmoon-action@v0.1.0. It is listed on the GitHub Marketplace (source at ASCIT31/darkmoon-action). OSS mode bind-mounts a data/reports dir and polls; Pro mode adds /api/v1 and SSE streaming.
• GitLab CI/CD component. A scan component published on the GitLab CI/CD Catalog. OSS mode points at the local engine (--oss-data-dir / --oss-script); Pro mode adds a --pro-url plus token and emits native GitLab Code-Quality and SAST reports.
• Jenkins plugin. A darkmoonScan step. The Jenkins Update Center listing is not live yet, so install the .hpi from GitHub Releases. OSS mode uses local data/reports dirs; Pro mode adds an API URL and emits SARIF 2.1.0 through Warnings-NG.

# .github/workflows/security.yml
jobs:
  darkmoon:
    runs-on: ubuntu-latest
    steps:
      - uses: ASCIT31/darkmoon-action@v0.1.0
        with:
          target: "https://staging.internal.example"   # a scope you own
          fail-on: exploited                            # gate the build

IDE: launch and browse without leaving the editor

Two editor extensions let a developer launch a campaign and browse findings next to the code that produced them.

• VS Code extension. Live on the VS Code Marketplace (publisher Darkmoon, verified). OSS mode browses and launches over a local data dir and CLI path; Pro mode connects a base URL and JWT for live status, the dashboard and remediation.
• JetBrains plugin. On the JetBrains Marketplace. OSS mode bridges to the client/CLI to browse and launch; Pro mode keeps the JWT in the IDE PasswordSafe and adds streaming, the dashboard and the remediation pull-request view.

Automation: DarkMoon as a node in your workflow

The n8n community node (n8n-nodes-darkmoon on npm) turns a campaign into a step in an n8n workflow: trigger a pentest, pull findings, retest, read metrics, wire webhooks, and review the fix pull requests the Pro remediation tier prepares. This node consumes the REST /api/v1 surface, so it is Pro-only — there is no OSS/local path in its code. It is a new package and we make no adoption claims yet. See DarkMoon for no-code and automation teams.

SecOps and observability: the metric on the board you already watch

• Splunk app. The open-source path exports a local JSON report (--export) and ingests it into Splunk over HEC, carrying safe fields only. The Splunkbase listing is not published yet, so install the .tar.gz from GitHub Releases. The Pro path adds a REST pull and a “Send to DarkMoon” alert action.
• Grafana app. A security-posture app plus a datasource that reads the Pro /api/v1 surface, so it is Pro-oriented. The grafana.com catalog listing is not live yet; install from GitHub Releases (or point the generic Infinity datasource at the REST API). Like the n8n node, the shipped datasource targets Pro.

The foundation: one SDK under all of it

Every surface above is built on the foundation client, @darkmoon_ai/client on npm, which also ships the darkmoon-ci binary. It has two backends: an oss-local backend that reads the local JSON store and spawns darkmoon.sh, and a pro-http backend that speaks the full /api/v1 surface with SSE. If you want your own integration, this is the layer to build on.

Which surface is which

Open source vs Pro, drawn plainly

The line is the same across every surface. Community is the open-source engine: the CLI, MCP, and a local JSON report — browse, launch and gate a build over data that never leaves your host. Pro adds the REST /api/v1 surface and everything that rides on it: live SSE streaming, the hosted dashboard, the remediation→pull-request loop, the scheduler and webhooks. The web dashboard and remediation→PR are Pro; they are never shipped as open source, and the two REST-only surfaces (the n8n node and the Grafana datasource) are therefore Pro by nature.

One privacy posture, everywhere

The reason it is safe to fan DarkMoon out across this many surfaces is that they all inherit the same egress rule. Findings are structured on the host with severity, CVSS, MITRE ATT&CK, ISO 27001 and full local evidence, but everything that leaves the host over an integration — the API, the HMAC-signed webhooks, the event stream, the Splunk export — carries only safe fields: counts, booleans, ids, MITRE tags and timestamps. Evidence bodies, secrets and raw requests and responses never cross those surfaces. That is enforced in the client redaction, the Splunk safe-field allow-list and the Grafana “evidence never exposed” rule alike. It is the same guarantee the investigation pipeline relies on end to end.

Where to start

If you ship through a pipeline, start with the CI/CD guide and the GitHub Action. If you live in an editor, install the VS Code or JetBrains plugin. If you orchestrate with n8n or watch a Grafana or Splunk board, those adapters read the Pro API. A full map of the surfaces is on the integrations page, and the engine underneath is on GitHub (GPL-3.0) with the documentation for each adapter.