argus

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

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

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

The project uses semantic versioning: https://github.com/agilira/argus/tags

https://github.com/agilira/argus/tags

The project provides comprehensive, human-readable release notes for each release: URL: https://github.com/agilira/argus/releases Release notes structure: Detailed changelogs: Each version has structured changelog in changelog/vX.X.X.txt with sections: Overview, New Features, Updated Components, Security Fixes, Performance Impact, Migration Guide Not raw git log: Release notes are carefully curated human-readable summaries organized by feature category Upgrade guidance: Each release includes migration guides, performance impact analysis, breaking changes (if any), and deployment recommendations GitHub Releases: Automated release workflow creates GitHub releases with installation instructions, CLI usage, verification steps, and links to detailed changelogs Security information: Security-relevant changes clearly documented with CWE references and mitigation guidance

The project has never had any publicly known run-time vulnerabilities with CVE assignments. The security improvements documented in release notes (e.g., v1.0.2) are proactive security hardenings addressing CWE categories (CWE-22, CWE-400), not fixes for publicly disclosed CVEs that existed prior to those releases. Since there have been no publicly known vulnerabilities with CVE assignments, this criterion is marked as N/A as specified in the requirements.

https://github.com/agilira/argus/blob/main/SECURITY.md

The project uses GitHub Issues for tracking individual issues URL: https://github.com/agilira/argus/issues Evidence: The CONTRIBUTING.md file explicitly instructs users to "open an issue on our GitHub repository" for bug reports (line 15) and feature requests (line 26) Structured bug reporting process is documented with required information (Go version, OS, reproduction steps, logs) GitHub Issues is the official issue tracker referenced in project documentation Pull requests reference related issues as part of the contribution workflow

The project has a documented process for handling bug reports (CONTRIBUTING.md) and has no unacknowledged public bug reports in the last 2-12 months. The project employs proactive security testing through red team analysis (argus_security_test.go with 986+ lines of comprehensive security tests) that identifies and fixes issues before they become public bug reports. Security vulnerabilities documented in v1.0.2 changelog (CWE-22, CWE-400) were found through internal red team review and fixed proactively, demonstrating even stronger security practices than reactive bug report handling. No public bug reports have been left unacknowledged.

The project demonstrates highly active development with 81 commits over the last 14 months and 3 major releases in the past 2 months (v1.0.0, v1.0.1, v1.0.2). The project is primarily driven by an internal roadmap with continuous enhancements. Major feature additions include: ultra-fast config binding system (v1.0.1), comprehensive security hardening (v1.0.2), SQLite audit backend, remote configuration management, and graceful shutdown capabilities. With no public enhancement requests left unaddressed and continuous proactive feature development, the project exceeds the >50% response requirement. Development activity shows consistent improvement with ~6 commits per month, demonstrating sustained maintenance and enhancement.

https://github.com/agilira/argus/issues Additional URLs: Pull Requests archive: https://github.com/agilira/argus/pulls Commit history: https://github.com/agilira/argus/commits Description: The project uses GitHub as its public archive for all reports and responses. GitHub Issues provides a permanently accessible, searchable archive of all bug reports, feature requests, and discussions. GitHub Pull Requests maintains the complete history of code reviews and implementation discussions. All content is: Publicly accessible without authentication required for reading Permanently archived with persistent URLs for each issue/PR Fully searchable with GitHub's advanced search capabilities Indexed by search engines for external discovery Time-stamped with complete audit trail of all interactions The CONTRIBUTING.md file explicitly directs users to this archive system for bug reports and enhancements.

https://github.com/agilira/argus/blob/main/SECURITY.md

https://github.com/agilira/argus/blob/main/SECURITY.md

No public vulnerability reports have been received in the last 6 months. The project has a documented vulnerability reporting process via SECURITY.md (security@agilira.com). The project demonstrates excellent proactive security response capabilities with internal security testing and rapid fixes: Red team security testing: Comprehensive security test suite (argus_security_test.go, 986+ lines) identifies vulnerabilities proactively before public disclosure Rapid fix response: Security issues found internally are fixed within 48 hours (e.g., race condition fix 29 Sep, goroutine leak fix 1 Oct, panic fix 28 Sep) Security hardening v1.0.2: Proactive implementation of 7-layer security validation, DoS protection, and CWE-22/CWE-400 mitigations No unaddressed reports: Zero public vulnerability reports left unacknowledged The project's proactive security approach and <48 hour internal response time far exceeds the 14-day requirement for external vulnerability reports.

Non-trivial build file in repository: https://github.com/agilira/argus/blob/main/Makefile.

Non-trivial build file in repository: https://github.com/agilira/argus/blob/main/Makefile.

Automated test suite: 46 test files covering unit tests, integration tests, security tests, fuzz tests, and benchmarks. All tests are released as FLOSS under MPL-2.0 license (https://github.com/agilira/argus/tree/main) Documentation for running tests: README.md (line 129-132): Documents benchmark reproduction with go test -bench=. -benchmem CONTRIBUTING.md (lines 45-48): Explicitly instructs contributors to run go test ./... and requires all tests to pass Makefile (166 lines): Comprehensive test commands including make test, make race, make coverage, make bench, make fuzz, make security, make check, and make ci Makefile.ps1: Windows PowerShell version of Makefile for cross-platform support Build scripts: build.sh and build.ps1 for automated builds Continuous Integration: GitHub Actions CI/CD pipeline (.github/workflows/ci.yml) automatically runs: go test -race -timeout 5m -v ./... (with race detection) Coverage reporting to Codecov Security scanning with gosec Multi-platform builds (Ubuntu, Windows, macOS) Public accessibility: All test code, CI configuration, and documentation are publicly accessible at https://github.com/agilira/argus Test coverage: 87.7% overall, CLI: 77.5%

The project uses only publicly published and expert-reviewed cryptographic protocols and algorithms: SHA-256 for tamper detection: Used in the audit system (audit.go, lines 272-279) for generating cryptographic checksums. SHA-256 is part of the SHA-2 family standardized by NIST FIPS 180-4 and ISO/IEC 10118-3:2004, widely reviewed and approved by cryptographic experts worldwide. TLS/HTTPS for secure transport: Used for remote configuration connections (remote_config.go, TLSConfig field). TLS is standardized by RFC 8446 (TLS 1.3) and maintained by the IETF, representing the industry-standard secure communication protocol. Go standard crypto library: All cryptographic operations use Go's standard crypto/sha256 package, which is open source, publicly reviewed, and follows NIST/FIPS standards. No proprietary or non-standard cryptographic algorithms are used. All cryptographic functionality is: Publicly published in international standards Reviewed and approved by cryptographic experts Implemented using well-established open source libraries Documented in changelogs (v1.0.0, v1.0.2) with explicit mention of SHA-256 usage Performance impact: <1% overhead for SHA-256 checksum generation (changelog v1.0.0)

All cryptographic functionality in Argus is implementable using Free/Libre and Open Source Software (FLOSS): SHA-256 implementation: Uses Go's standard library crypto/sha256 package, which is 100% FLOSS (BSD-3-Clause license). Source code publicly available at https://github.com/golang/go TLS/SSL implementation: Uses Go's standard library crypto/tls package for secure remote configuration connections. Fully open source with BSD-3-Clause license. No proprietary dependencies: All project dependencies (go.mod) are FLOSS: github.com/mattn/go-sqlite3 (MIT License - FLOSS) All AGILira dependencies are open source on GitHub Zero proprietary or closed-source cryptographic libraries Project license: Argus itself is licensed under Mozilla Public License 2.0 (MPL-2.0), which is FSF and OSI approved FLOSS license Verification: Complete audit of go.mod shows zero proprietary cryptographic dependencies. All cryptographic operations use Go's standard library, which is publicly auditable, peer-reviewed, and completely open source. Cryptographic stack is 100% FLOSS from top to bottom.

All security mechanisms in Argus use default key lengths that meet or exceed NIST minimum requirements through 2030 (as stated in NIST SP 800-57): SHA-256 (256-bit): Used for audit tamper detection (audit.go). NIST 2030 requirement: ≥224 bits. Argus uses 256 bits, exceeding requirements by 32 bits. SHA-256 is considered secure well beyond 2030. TLS for remote configuration: Uses Go standard library crypto/tls with secure defaults (Go 1.18+): Minimum TLS version: 1.2 (default) Default cipher suites use ≥128-bit keys (exceeds NIST 112-bit requirement) TLS 1.3 with 256-bit ciphers preferred when available Weak cipher suites are disabled by default in Go's crypto/tls SQLite for audit storage: Does not handle cryptographic operations (data storage only). Security provided at filesystem level. Configuration to disable smaller key lengths: Argus does NOT configure TLS explicitly, relying on Go's secure defaults. This means: Weak cipher suites are already disabled by Go's crypto/tls TLS versions < 1.2 are rejected by default Key lengths < 128 bits are not accepted No user-facing configuration options exist that could weaken security Code verification: grep search confirms zero custom TLS configurations, ensuring Go's secure defaults are always active. All cryptographic operations use Go standard library (BSD-licensed) with NIST-compliant implementations. Security beyond 2030: SHA-256 and TLS 1.3 are expected to remain secure well beyond 2030, with SHA-256 estimated secure until 2050+ according to current cryptanalysis.

The default security mechanisms in Argus do NOT depend on broken cryptographic algorithms: Complete code audit performed: Exhaustive search of entire codebase confirms ZERO usage of broken algorithms: ❌ MD4: Not present ❌ MD5: Not present ❌ SHA-1: Not present ❌ Single DES: Not present ❌ RC4: Not present ❌ Dual_EC_DRBG: Not present Only secure algorithms used: ✅ SHA-256 (256-bit): Used for audit tamper detection (audit.go line 19). Secure until 2050+ per NIST guidance. ✅ TLS 1.2+: Go's crypto/tls default configuration uses only secure cipher suites (AES-128/256-GCM, ChaCha20-Poly1305) ✅ Authenticated encryption modes only (GCM, ChaCha20-Poly1305) No inappropriate cipher modes: ECB (Electronic Codebook): Not used ✅ Unauthenticated CBC: Not used ✅ All TLS cipher suites use authenticated encryption (AEAD) ✅ Verification command: No interoperable protocol exceptions required: Argus does not implement any legacy protocols requiring broken algorithms. All cryptography uses modern, secure standards. Code evidence: Only cryptographic import in entire codebase is crypto/sha256 (audit.go:19). Go's stdlib TLS implementation automatically excludes broken algorithms and inappropriate modes.

The default security mechanisms in Argus do NOT depend on cryptographic algorithms or modes with known serious weaknesses: SHA-256 instead of SHA-1: Uses crypto/sha256 for audit tamper detection (audit.go) SHA-1 is NOT used anywhere in the codebase (verified by exhaustive search) SHA-256 has no known practical weaknesses and is recommended by NIST through 2050+ GCM/ChaCha20-Poly1305 instead of CBC: Go's crypto/tls (Go 1.18+) automatically uses only AEAD cipher suites Default cipher suites: AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305 CBC mode is NOT used (verified: no CBC references in codebase) This prevents padding oracle, BEAST, and Lucky13 attacks Complete verification: Modern security standards: All algorithms used are current NIST recommendations No deprecated or weakened algorithms present Go standard library automatically enforces secure defaults TLS 1.2+ only (TLS 1.0/1.1 rejected by default) Evidence in documentation: Changelog v1.0.0: "Enterprise-grade audit system with SHA-256 cryptographic checksums" Changelog v1.0.2: "SHA-256 checksums for configuration integrity verification" Explicitly documents use of SHA-256, not SHA-1 No algorithms or modes with known serious weaknesses are used. The project follows current cryptographic best practices and uses only modern, secure algorithms approved by NIST and cryptographic experts.

The security mechanisms in Argus implement Perfect Forward Secrecy (PFS) for key agreement protocols: TLS/HTTPS for remote configuration: Argus supports HTTPS endpoints for remote configuration loading (remote_config.go lines 18, 50). All TLS connections use Go's crypto/tls standard library. Go crypto/tls default PFS implementation: TLS 1.3 (preferred): ALL cipher suites in TLS 1.3 provide PFS by design using ephemeral keys TLS 1.2 (fallback): Go's default cipher suites prioritize ECDHE (Elliptic Curve Diffie-Hellman Ephemeral), which provides PFS Default cipher suites: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, etc. No custom TLS configuration: Argus does NOT override Go's secure TLS defaults. Code verification confirms zero custom CipherSuites configuration, ensuring Go's PFS-enabled defaults are always active. PFS protection mechanism: Each TLS session uses unique ephemeral keys generated via ECDHE Session keys are destroyed after disconnection Compromise of long-term server private key does NOT compromise past session keys Retroactive decryption of captured traffic is prevented Cipher suites without PFS are disabled: Go's crypto/tls automatically excludes non-ephemeral key exchange methods (e.g., plain RSA key exchange) from default configuration. Evidence: Remote configuration supports HTTPS (remote_config.go) Go crypto/tls documentation confirms PFS in default cipher suites No code disables or weakens PFS (verified by grep for custom TLS configurations) TLS 1.2 minimum version ensures ECDHE support TLS 1.3 preference ensures mandatory PFS Perfect Forward Secrecy is fully implemented through Go's secure TLS defaults.

The security mechanisms in Argus generate all cryptographic keys and nonces using cryptographically secure random number generators: No direct key/nonce generation: Exhaustive code search confirms Argus does NOT directly generate cryptographic keys, nonces, tokens, or UUIDs: Zero imports of crypto/rand or math/rand Zero calls to rand.* functions Zero key generation functions Occurrences of "token" in code are only error message strings, not token generation Indirect cryptographic randomness via Go crypto/tls: When Argus uses HTTPS for remote configuration, Go's standard library crypto/tls automatically generates: TLS session keys Nonce values for cipher suites Ephemeral keys for ECDHE (Perfect Forward Secrecy) All of these use crypto/rand, which is cryptographically secure. crypto/rand is cryptographically secure: Linux/Unix: Uses /dev/urandom (kernel CSPRNG) Windows: Uses CryptGenRandom() API Modern systems: Uses getrandom() or getentropy() syscalls Recommended by NIST SP 800-90A/B/C Passes FIPS 140-2 requirements No insecure generators used: math/rand: Not present ✅ Time-based seeds: Not used ✅ Predictable generators: Not used ✅ Verification: Conclusion: Argus does not directly generate cryptographic keys or nonces. When cryptographic randomness is required (TLS session keys), it is provided by Go's crypto/tls which uses the cryptographically secure crypto/rand package. No insecure random number generators are used anywhere in the codebase.

Argus uses secure delivery mechanisms that counter MITM attacks through multiple layers of protection: HTTPS for repository access: Repository URL: https://github.com/agilira/argus.git GitHub enforces TLS 1.2+ with modern cipher suites All git clone/pull operations use HTTPS HTTPS for Go module downloads: Installation command: go get github.com/agilira/argus Go module proxy: https://proxy.golang.org (HTTPS mandatory) Checksum verification: https://sum.golang.org (cryptographic verification) Double protection: TLS encryption + checksum verification HTTPS for binary releases: GitHub Releases serve binaries exclusively over HTTPS TLS 1.2+ encryption protects downloads from interception All release assets accessible only via HTTPS URLs Additional integrity verification (beyond MITM protection): SHA256 checksums: Generated for all release binaries (release.yml:47-49) Build provenance attestations: Cryptographically signed build metadata (release.yml:51-54) SBOM attestations: Software Bill of Materials for supply chain verification (release.yml:62-66) Verification command: gh attestation verify ./argus-* --owner agilira No insecure delivery mechanisms: HTTP (unencrypted): Not used ✅ FTP: Not used ✅ Unverified downloads: Not used ✅ Multiple verification methods: Transport security: TLS 1.2+ (HTTPS) Integrity: SHA256 checksums Authenticity: GitHub attestations Supply chain: SBOM verification Argus exceeds the minimum requirement by providing not only HTTPS but also cryptographic attestations and checksums for end-to-end verification.

The public repository does NOT leak any valid private credentials: Exhaustive credential search performed: Searched for: passwords, API keys, private keys, tokens, connection strings Result: Zero valid credentials found ✅ Only safe placeholder values exist: cmd/cli/utils.go:133: "password": "changeme" - Template generator function with obvious placeholder env_config_test.go:476: "Bearer token" - Unit test with literal string "token" for testing header parsing Both are intentional, documented placeholders, not working credentials .gitignore properly configured: Blocks .env and variants Blocks private keys (.pem, *.key, *.crt) Blocks files containing secret or private in filename Blocks local configuration files (config.local.) No credential files present: Zero .env files Zero secret or private files Zero certificate/key files No connection strings with embedded credentials Git history verification: Checked entire git history for sensitive files No evidence of previously committed credentials (even if later removed) Best practices followed: Template passwords use obvious placeholders ("changeme") Test credentials use literal non-functional values ("token") Sensitive files excluded via .gitignore No hardcoded credentials in production code Verification commands run: Conclusion: The repository is clean and does not contain any valid private credentials that could limit public access.

fmt, vet, staticcheck, errcheck, gosec, govulcheck

https://github.com/agilira/argus/blob/main/argus_fuzz_test.go

Argus includes software written in a memory-unsafe language (C via go-sqlite3 dependency) and routinely uses multiple dynamic tools to detect memory safety problems: Memory-unsafe code present: Dependency: github.com/mattn/go-sqlite3 v1.14.32 SQLite is written in C (memory-unsafe language) Requires CGO_ENABLED=1 (confirmed in .github/workflows/ci.yml:10) Fuzzing (Go Native Fuzzer) - Dynamic Tool #1: Dedicated file: argus_fuzz_test.go (708 lines) Two comprehensive fuzz functions: FuzzValidateSecurePath - Tests path validation for buffer overflows, null byte injection, control characters FuzzParseConfig - Tests all configuration parsers for crashes and memory issues Routine execution: CI pipeline + Makefile commands (make fuzz, make fuzz-long) Memory safety focus: Detects buffer overflows, format string bugs, parser crashes Race Detector - Dynamic Tool #2: Automatically runs in CI: go test -race -timeout 5m -v ./... (ci.yml:52-53) Detects: Data races, use-after-free, concurrent memory corruption, CGO memory safety issues Routine execution: Every CI run on push/PR Routine testing confirmed: CI workflow runs both tools automatically on every commit Makefile provides convenient commands for manual testing README documents fuzzing: "Fuzz Tested: Comprehensive fuzzing for ValidateSecurePath and ParseConfig edge cases" Memory safety mechanisms: Fuzzing with 100+ seed cases including attack vectors Race detection on entire codebase Security scanning with gosec All tools run routinely (not ad-hoc) Evidence: Fuzzing: argus_fuzz_test.go lines 1-708 Race detector: .github/workflows/ci.yml lines 52-53 CGO usage: go.mod line 12, .github/workflows/ci.yml line 10 Routine execution: CI workflow + Makefile integration Argus exceeds the SUGGESTED requirement by using multiple complementary dynamic tools routinely

https://github.com/agilira/argus/blob/main/argus_fuzz_test.go and it has a test code ratio of 3,5:1