opnDossier

Repository on GitHub, which provides public git repositories with URLs.

URL: https://github.com/EvilBit-Labs/opnDossier

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

All development happens on feature branches with pull requests reviewed before merging to main. The full commit history and interim development state is preserved in the repository. Releases are tagged separately via GoReleaser.

Repository on GitHub, which uses git. git is distributed.

We use SemVer. Each release gets a unique vX.Y.Z git tag. GoReleaser automates release creation from tags. No two releases share the same version string. Published releases: v1.0.0-rc1, v1.0.0, v1.1.0, v1.2.1.

We use git tags that match the SemVer number (e.g., "v1.2.1").

Non-trivial release notes file in repository: https://github.com/EvilBit-Labs/opnDossier/blob/main/CHANGELOG.md.

No CVEs have been assigned against the project. No publicly known vulnerabilities have needed to be disclosed in release notes. If vulnerabilities are discovered in the future, they will be identified in release notes per the project's security policy.

The project uses GitHub Issues to allow users to submit public bug reports. An issue template is provided to guide reporters through structured bug reports with reproduction steps, expected/actual behavior, and environment details.

URL: https://github.com/EvilBit-Labs/opnDossier/issues

The project uses GitHub Issues to allow users to submit and track issue reports.

URL: https://github.com/EvilBit-Labs/opnDossier/issues

The project has 100 issues filed (76 closed, 24 open), including 16 bug reports. All issues are acknowledged and triaged by the maintainer. The single maintainer actively responds to all issues.

URL: https://github.com/EvilBit-Labs/opnDossier/issues

The single maintainer actively responds to all enhancement requests. All issues are triaged and organized into milestones.

All issues are tracked via GitHub Issues, which is public and searchable.

URL: https://github.com/EvilBit-Labs/opnDossier/issues

The project publishes a comprehensive security policy with multiple reporting channels: GitHub's private vulnerability reporting (enabled), email (support@evilbitlabs.io with PGP key), and GitHub Security Advisories. Public issues are explicitly discouraged for vulnerabilities. The policy includes scope definition, safe harbor provisions, and response timelines.

URL: https://github.com/EvilBit-Labs/opnDossier/blob/main/SECURITY.md

The project supports private vulnerability reporting through two channels: GitHub's private vulnerability reporting feature (preferred) and PGP-encrypted email to support@evilbitlabs.io (fingerprint: F839 4B2C F0FE C451 1B11 E721 8F71 D62B F438 2BC0).

URL: https://github.com/EvilBit-Labs/opnDossier/blob/main/SECURITY.md

While the project has a published process with defined response timelines (1 week acknowledgment, 2 weeks initial assessment), there have been no vulnerability reports received in the last 6 months.

Standard Go build system. The project uses go build to compile from source, automatically resolving and fetching dependencies via Go modules. go install builds and installs the binary. The project also uses GoReleaser for cross-platform release builds. A justfile provides convenient build targets (just build, just build-release).

URL: https://github.com/EvilBit-Labs/opnDossier/blob/main/justfile

Go's built-in build system is the standard build tool for Go; equivalent to Maven for Java or npm for Node.js. No custom build tooling. The justfile wraps standard Go commands for convenience.

Go is open source (BSD-3-Clause license). All build tools used are FLOSS: Go toolchain, GoReleaser (MIT), just (CC0), golangci-lint (GPL-3.0), git-cliff (MIT/Apache-2.0).

The project has an automated test suite across 30 packages run via go test ./... and documented in the justfile (just test). Tests run automatically in CI via GitHub Actions on every push and PR. The CI workflow is publicly visible. Test coverage is 71.5% of statements, measured by Go's built-in coverage tooling.

URL: https://github.com/EvilBit-Labs/opnDossier/blob/main/.github/workflows/ci.yml

Test suite is triggered by standard Go commands (go test ./...) and also uses just as a task runner (just test, just test-race, just test-coverage).

GitHub Actions CI runs on every push and PR. The pipeline includes linting, cross-platform testing (Ubuntu, macOS, Windows), integration tests, coverage reporting to Codecov, and build verification.

URL: https://github.com/EvilBit-Labs/opnDossier/blob/main/.github/workflows/ci.yml

The project's AGENTS.md (section 12.1) requires "Write comprehensive tests for new functionality" and the CONTRIBUTING.md requires ">80% coverage" for all PRs. The PR template includes a checklist item for test coverage. CI enforces test passage before merge.

URL: https://github.com/EvilBit-Labs/opnDossier/blob/main/CONTRIBUTING.md

Every merged PR in the project's recent history includes tests alongside new functionality. For example:

• PR #257 (audit logging levels) — added tests
• PR #256 (deterministic map output) — added tests
• PR #254 (Dest Port column fix) — added tests
• PR #252 (security overhaul) — added fuzz tests
• PR #245 (HTML diff formatter) — added tests
• PR #237 (IDS/Suricata parsing) — added tests
• PR #234 (sanitize command) — added tests

URL: https://github.com/EvilBit-Labs/opnDossier/pulls?q=is%3Apr+is%3Amerged

Documented in CONTRIBUTING.md under the Quality Standards section: "Tests required for new functionality (>80% coverage)." The PR template checklist explicitly includes test requirements. AGENTS.md section 7 provides detailed test organization guidance and section 12.1 mandates writing comprehensive tests.

URL: https://github.com/EvilBit-Labs/opnDossier/blob/main/CONTRIBUTING.md

The project enforces multiple layers of code quality checking:

• golangci-lint v2.8 with 38 active linters (including gosec for security, gocritic for correctness, staticcheck for bugs)
• gofumpt for strict formatting (stricter than gofmt)
• CodeQL via GitHub Actions for semantic security analysis
• Grype and Snyk for dependency vulnerability detection

URL: https://github.com/EvilBit-Labs/opnDossier/blob/main/.golangci.yml

Zero linter warnings. The CI enforces all warnings; the build fails if any linter issue is found. The project currently passes with zero golangci-lint issues across the entire codebase.

The project uses 38 active linters including strict options. gofumpt (stricter than gofmt) is enforced. gosec checks for security issues. gocritic with performance and diagnostic tags. The project has documented rationale for each disabled linter in .golangci.yml.

URL: https://github.com/EvilBit-Labs/opnDossier/blob/main/.golangci.yml

The primary developer has experience developing secure software for high-security and government environments. The project reflects secure design principles in practice: economy of mechanism (pure Go, minimal dependencies), fail-safe defaults (XXE-safe by default, offline-first, overwrite protection), complete mediation (typed structs, Cobra validation), input validation, and limited attack surface (read-only file operations, no network exposure). The project maintains a formal security assurance case documenting Saltzer and Schroeder design principles.

URL: https://github.com/EvilBit-Labs/opnDossier/blob/main/docs/security/security-assurance.md

The primary developer knows common security errors and the project's security assurance case maps countermeasures against CWE/SANS Top 25 vulnerabilities: XXE (CWE-611), path traversal (CWE-22), command injection (CWE-78), improper input validation (CWE-20), resource exhaustion (CWE-400), and untrusted deserialization (CWE-502). Each has documented mitigations.

URL: https://github.com/EvilBit-Labs/opnDossier/blob/main/docs/security/security-assurance.md

Multiple layers:

• Source code delivered via GitHub over HTTPS/SSH
• Releases built with GoReleaser and signed with Cosign v3 keyless signatures (Sigstore transparency log)
• SLSA Level 3 provenance attestations via actions/attest-build-provenance
• Dependencies fetched by Go modules over HTTPS
• SHA256 checksums published with each release
• Homebrew formula delivered via tap repository over HTTPS

URL: https://github.com/EvilBit-Labs/opnDossier/releases

The project does not retrieve or verify cryptographic hashes over HTTP. All dependency resolution is handled by Go modules over HTTPS, and release artifacts include Cosign signatures and provenance attestations via Sigstore.

Zero known vulnerabilities. Grype and Snyk run in CI on every push. CodeQL runs on every push. No CVEs have been filed against the project. Dependabot is configured for automated dependency updates across four ecosystems.

URL: https://github.com/EvilBit-Labs/opnDossier/blob/main/.github/workflows/ci.yml

No critical vulnerabilities have been reported. The project has a documented security policy with response timelines (1 week acknowledgment, 2 weeks assessment, 90 days fix target), private vulnerability reporting enabled, and automated dependency scanning running on every push.

URL: https://github.com/EvilBit-Labs/opnDossier/blob/main/SECURITY.md

GitHub secret scanning and push protection are both enabled on the repository. No credentials are stored in the codebase. The .gitignore excludes .env files and all variants (.env.local, .env.development.local, etc.). Pre-commit hooks check for common credential patterns.

Multiple static analysis tools run on every PR and pre-release:

• golangci-lint (beyond compiler warnings: includes 38 linters for correctness, security, performance, and style)
• CodeQL via GitHub Actions for semantic security analysis
• gosec (within golangci-lint) for Go-specific security vulnerabilities
• Grype for known vulnerability detection in dependencies
• Snyk for additional dependency and code scanning
• OSSF Scorecard for supply chain security assessment

URL: https://github.com/EvilBit-Labs/opnDossier/blob/main/.github/workflows/ci.yml

CodeQL specifically targets common vulnerabilities (injection, buffer overflows, insecure data handling). gosec checks for Go-specific security issues. Grype checks dependencies against the National Vulnerability Database for known CVEs.

URL: https://github.com/EvilBit-Labs/opnDossier/blob/main/.github/workflows/ci.yml

CI enforces zero tolerance for golangci-lint and CodeQL findings; both block merging if issues are found. No outstanding static analysis findings exist.

URL: https://github.com/EvilBit-Labs/opnDossier/blob/main/.github/workflows/ci.yml

golangci-lint and CodeQL run on every push to main and on every pull request. Static analysis occurs on every commit, not just daily.

URL: https://github.com/EvilBit-Labs/opnDossier/blob/main/.github/workflows/ci.yml

The project uses go test -race for race condition detection at runtime, and includes property-based fuzz tests (via Go's built-in fuzzing framework) that exercise the parser with randomized inputs to probe for runtime failures. go test itself executes code with specific inputs, qualifying as dynamic analysis.

The project is pure Go, which is a memory-safe language. Go uses garbage collection and bounds-checked arrays. The project does not use the unsafe package. No memory-unsafe languages are used.

Go's testing framework includes assertion-style checks via testify assertions. The fuzz tests generate randomized inputs that exercise assertion paths. Race detection (go test -race) enables runtime assertions for concurrent access violations. Go's built-in bounds checking is always active (panics on out-of-bounds access).

No dynamic analysis vulnerabilities have been discovered. All test suites pass with zero failures. Race detection passes cleanly.