Documents
GitHub Issue Plan
GitHub Issue Plan
Type
External
Status
Published
Created
Mar 22, 2026
Updated
Apr 3, 2026
Updated by
Dosu Bot

Derived from the Product Strategy and Open Core Implementation Roadmap Notion documents.#

Part A: Open Repo — v1.3.0 Milestone#

Create a v1.3.0 milestone in EvilBit-Labs/opnDossier and assign the following existing issues to it.

Critical-path issues (tag with milestone v1.3.0)#

These are the 5 gating items that the pro repo depends on:

IssueTitleWhy Critical
#280Finding type unificationPro repo shouldn't deal with three different Finding types
#301Public schemas / CommonDevice as public packagesPro repo must import these as a Go module dependency
#302DeviceParser registryInterface the pro repo uses to register additional parsers
#321Shared analysis package extractionEliminates converter/processor duplication that would mirror into pro
#279(Overlaps with #321)Review whether this is a duplicate; if so, close one and keep the other in milestone
### Additional issues for v1.3.0
IssueTitleNotes
#197pfSense parserHigh demand, second platform. All parsers stay in the open repo (free forever). If not ready for v1.3.0, ships in v1.3.1.
### New issue to create in open repo **Title:** Remove STIG plugin from open repo (migrate to pro) **Labels:** `breaking-change`, `open-core` **Body:** ```javascript As part of the open core transition, the STIG compliance plugin at internal/plugins/stig/ is moving to the opnDossier-pro repository. This code will be removed from the open repo.

SANS/NSA best practice checks and Cybersecurity Best Practices checks remain in the open
repo as Community-tier features.

This is a planned change documented in the product strategy. The STIG plugin is the only
feature being moved from free to paid.

Tasks:

  • Ensure STIG plugin code is copied to pro repo first
  • Remove internal/plugins/stig/ from open repo
  • Update plugin registration to exclude STIG
  • Update documentation to note STIG is a Pro feature
  • Add release note explaining the change

Blocked by: Pro repo Phase 2 scaffold (license validation must work before migration)

**Milestone:** Do NOT assign to v1.3.0. This happens after v1.3.0 ships, during Phase 3.
---
## Part B: Pro Repo — Phase 2 Issues (Scaffold + Licensing)
Create these issues in `EvilBit-Labs/opnDossier-pro`. Suggested labels: `scaffold`, `licensing`, `infra`.
### P2-1: Initialize Go module with open repo dependency
**Labels:** `scaffold`
```javascript
Initialize the opnDossier-pro Go module that imports
github.com/EvilBit-Labs/opnDossier as a dependency.

Tasks:
- [ ] go mod init github.com/EvilBit-Labs/opnDossier-pro
- [ ] Add open repo as a dependency (go get github.com/EvilBit-Labs/opnDossier@v1.3.0)
- [ ] Create basic main.go that imports and wraps the community CLI
- [ ] Verify go build produces a working binary with community behavior
- [ ] Set up basic CI (GitHub Actions: build, test)

Depends on: open repo v1.3.0 tagged and published as Go module

P2-2: Generate Ed25519 keypair#

Labels: licensing, security

Generate the Ed25519 keypair used for license signing and validation.

Tasks:
- [ ] Generate Ed25519 keypair
- [ ] Store private key securely (NOT in repo -- use GitHub Secrets, 1Password, or similar)
- [ ] Document key storage location and access procedures
- [ ] Create embed directive for public key in Go source

Security notes:
- Private key never enters any git repository
- Public key is embedded in the pro binary at compile time
- Key rotation procedure should be documented (even if not implemented yet)

Depends on: P2-1 (repo initialized)

P2-3: Implement license validation package#

Labels: licensing

Implement the license package that handles license file discovery, decryption,
validation, and feature gating.

License blob structure (from product strategy):
{
  "license_id": "lic_xxxxxxxx",
  "licensee": "Acme Security Consulting",
  "email": "ops@acmesec.io",
  "tier": "professional",
  "features": ["stig", "topology", "red-blue-reports"],
  "issued_at": "2026-04-01T00:00:00Z",
  "expires_at": "2027-04-01T00:00:00Z",
  "offline": false
}

Tasks:
- [ ] Define license blob JSON schema as Go struct
- [ ] Implement Ed25519 signature verification using embedded public key
- [ ] License file discovery: config directory, --license flag, OPNDOSSIER_LICENSE env var
- [ ] Tier checking: map tier string to feature set
- [ ] Feature array checking: granular feature gating beyond tier defaults
- [ ] Expiration enforcement with graceful degradation to Community behavior
- [ ] Demo/trial license support (same mechanism, short expiration)
- [ ] Comprehensive test suite: valid license, expired license, wrong signature,
      missing license (degrades to community), malformed JSON, future-dated license

Design decisions:
- Perpetual per major version for paid tiers (Professional, Enterprise, Gov/IC)
- Time-bounded for demo/trial licenses
- Community features always available regardless of license state
- Binary without license == community binary behavior

Depends on: P2-2 (keypair generated)

P2-4: Build license generation CLI tool (internal)#

Labels: licensing, tooling

Build a CLI tool for generating and signing license blobs. This tool is internal
only -- it runs on EvilBit Labs infrastructure, not distributed to customers.

Tasks:
- [ ] CLI that reads private key from file/env
- [ ] Accepts: licensee name, email, tier, features array, expiration date
- [ ] Generates signed JSON license blob
- [ ] Outputs to file (for email delivery) or stdout
- [ ] Support for demo license generation (preset: 14-day, full Pro features)
- [ ] Support for trial license generation (configurable duration and feature subset)
- [ ] Validate generated license with the public key (round-trip test)

Usage examples:
  opndossier-license-gen --licensee "Acme Security" --email ops@acme.io \
    --tier professional --expires 2027-04-01
  opndossier-license-gen --demo # 14-day full Pro trial

Depends on: P2-2 (keypair), P2-3 (license schema)

P2-5: Implement conditional feature registration#

Labels: scaffold

Implement the mechanism by which Pro plugins and CLI commands register themselves
only when the license permits.

Tasks:
- [ ] Pro plugin registration that checks license tier before registering
- [ ] Pro CLI commands that appear only when licensed (e.g., opndossier-pro stig
      only shows if license includes "stig" feature)
- [ ] Graceful behavior when unlicensed: binary behaves identically to community build
- [ ] License status command: opndossier-pro license status shows current license
      info (tier, features, expiration) or "No license found -- running in Community mode"
- [ ] Test: build without license, compare behavior to community binary
- [ ] Test: build with license, confirm gated features appear

Design: Use Go build tags or runtime registration pattern. The open repo's plugin
registry (#302) should support this without modification.

Depends on: P2-1 (module), P2-3 (license package)
Depends on: open repo #302 (DeviceParser registry)

P2-6: Set up GoReleaser config for opndossier-pro#

Labels: infra

Configure GoReleaser to build and release the opndossier-pro binary.

Tasks:
- [ ] Create .goreleaser.yml for opndossier-pro
- [ ] Target same platforms as community binary
- [ ] Binary name: opndossier-pro (distinct from community opndossier)
- [ ] Packaging: deb, rpm, apk
- [ ] Docker images via GHCR (ghcr.io/evilbit-labs/opndossier-pro)
- [ ] GitHub Actions workflow for release automation
- [ ] Embed public key at build time (via ldflags or embed directive)
- [ ] Test: build release locally, verify binary names and packages

Mirror the community repo's GoReleaser setup as closely as possible.

Depends on: P2-1 (module), P2-2 (public key for embedding)

P2-7: End-to-end validation gate#

Labels: testing

Validate the complete Phase 2 scaffold before moving to feature development.

Validation checklist:
- [ ] Build opndossier-pro binary from pro repo
- [ ] Run without license: confirm identical behavior to community opndossier binary
- [ ] Create test license with license-gen CLI
- [ ] Run with test license: confirm license status command shows correct info
- [ ] Run with expired license: confirm graceful degradation to Community
- [ ] Run with invalid signature: confirm rejection
- [ ] Build community binary from open repo: confirm zero awareness of pro repo or licensing
- [ ] GoReleaser: produce release artifacts locally
- [ ] CI: green build on all target platforms

This is a gate, not a feature. All items must pass before Phase 3 begins.

Depends on: P2-1 through P2-6 (all Phase 2 tasks)

Part C: Pro Repo — Phase 3 Issues (MVP Features)#

P3-1: Migrate STIG compliance plugin from open repo#

Labels: feature, compliance

Move the STIG compliance plugin from the open repo (internal/plugins/stig/) to the
pro repo. This is the only feature being moved from free to paid.

Tasks:
- [ ] Copy STIG plugin code from open repo to pro repo
- [ ] Adapt imports to work with the pro module structure
- [ ] Register STIG plugin conditionally (only when license includes "stig" feature)
- [ ] Write tests: STIG checks run with valid license, do not appear without license
- [ ] Coordinate with open repo: create the STIG removal issue (see Part A)
- [ ] Verify SANS/NSA checks still work in community binary after STIG removal

Timing: The pro repo gets the code first. The open repo removal happens in a
coordinated release (not before the pro binary can run STIG checks).

Depends on: P2-5 (conditional registration), P2-7 (validation gate passed)

P3-2: Implement structured remediation guidance (#206)#

Labels: feature

Add concrete fix-it instructions to findings. High value for consultants writing
assessment reports.

Example: A finding "HIGH: unrestricted SSH from ANY source" should include
remediation like "Restrict SSH source to admin VLAN (e.g., 10.0.1.0/24),
implement jump host architecture, consider SSH key-only authentication."

Tasks:
- [ ] Design remediation data structure (per-finding, per-platform where relevant)
- [ ] Add remediation text to existing Cybersecurity Best Practices findings
- [ ] Add remediation text to STIG findings
- [ ] Add remediation text to SANS/NSA findings
- [ ] Include remediation in all output formats (Markdown, JSON, YAML)
- [ ] Gate behind Pro license (remediation guidance is a Pro feature)
- [ ] Tests: verify remediation appears with license, absent without

Note: This corresponds to open repo issue #206. The implementation lives in the
pro repo since it's a Pro-tier feature. The open repo issue can be closed with a
note pointing to the pro implementation.

Depends on: P2-5 (conditional registration), P3-1 (STIG migration)

P3-3: MVP integration testing#

Labels: testing

End-to-end testing of the complete MVP feature set before soft launch.

Test scenarios:
- [ ] Community binary: parse OPNsense config, verify findings, verify no Pro features
- [ ] Pro binary (no license): same behavior as community
- [ ] Pro binary (Pro license): parse OPNsense config with STIG checks and remediation
- [ ] Pro binary (Pro license): parse pfSense config with STIG checks and remediation
- [ ] Pro binary (expired license): graceful degradation, STIG checks disappear
- [ ] Pro binary (demo license): full Pro features for 14 days, then degrades
- [ ] Output format testing: all formats (MD, JSON, YAML) include remediation when licensed
- [ ] License activation: file placement, CLI flag, and env var all work
- [ ] Error messages: clear, helpful messages for license issues

This validates the complete user experience before demo licenses go out.

Depends on: P3-1 (STIG migration), P3-2 (remediation guidance)

Part D: Placeholder Epics (Phase 4-5)#

Create these as tracking issues. Full task breakdowns come later.

P4-1: Sales infrastructure#

Labels: epic, sales

Set up the minimal sales infrastructure needed for commercial launch.

Scope:
- Payment processor integration (Stripe or similar)
- License generation triggered on purchase (webhook -> license-gen CLI -> email)
- Demo license request form
- Enterprise/Gov-IC contact form (routes to Krystal)
- Refund/cancellation policy

See launch sequence document for detailed requirements.

P4-2: Pro documentation#

Labels: epic, docs

Extend the mkdocs documentation site with Pro feature coverage.

Scope:
- Pro feature documentation (STIG, remediation guidance)
- License activation guide (file, CLI flag, env var)
- Tier comparison page
- Migration guide for STIG users (community -> pro transition)
- FAQ: licensing, offline use, major version upgrades

P4-3: First Pro release checklist#

Labels: epic, release

Tracking issue for the v1.0.0-pro release.

Checklist:
- [ ] Pro binary builds and passes all tests
- [ ] License validation works end-to-end (purchase -> generate -> email -> activate)
- [ ] Demo license flow works (request -> generate -> email -> 14-day trial)
- [ ] Product website live with tier comparison, pricing, download
- [ ] Documentation covers Pro features and license activation
- [ ] Announcement prepared: GitHub release notes, Reddit posts, blog post
- [ ] STIG removal from open repo coordinated with pro release

See launch sequence document for announcement details.

Dependency Graph#

Open Repo v1.3.0
  #280 Finding type unification
  #301 Public schemas
  #302 DeviceParser registry ──────────────────────┐
  #321 Shared analysis extraction │
  #279 (review for duplicate with #321)  #197 pfSense parser │
       │ │
       v │
Pro Phase 2 (Scaffold)  P2-1 Go module init ─────┬───────────────────┐ │
  P2-2 Ed25519 keypair ────┤ │ │
       │ │ │ │
       v v v v
  P2-3 License pkg P2-6 GoReleaser P2-5 Conditional registration
       │ │ │
       v │ │
  P2-4 License gen CLI │ │
       │ │ │
       └───────────────────┴───────────────────┘
                           v
                    P2-7 Validation gate
                           v
Pro Phase 3 (MVP)
  P3-1 STIG migration ────────────────┐
  P3-2 Remediation guidance ──────┤
       │ │
       v v
  Open repo: STIG removal P3-3 Integration testing
                                   v
Pro Phase 4-5 (Launch)
  P4-1 Sales infra
  P4-2 Pro documentation
  P4-3 Release checklist