// Security Documentation

Security Policy

EFFECTIVE DATE: JANUARY 1, 2025  •  LAST UPDATED: 2025

Darkbloom Industries™ is committed to delivering software and systems built to the highest security standards available in the commercial and defense sectors. This Security Policy describes the frameworks, standards, and practices we are capable of implementing across client engagements, as well as the security posture of our own infrastructure.

Note: Darkbloom Industries™ delivers audit-ready, standard-aligned implementations. We are not a certified CMMC assessment organization (C3PAO) and do not perform official third-party certification assessments.

1. Compliance Framework Alignment (Capabilities)

The following frameworks represent the standards we can align with. The specific controls implemented for any given project are determined by client requirements, project scope, and budget.

2. Cryptography Standards (Optional)

When cryptographic implementations are required and scoped into a project, we utilize FIPS 140-3 validated modules and algorithms:

• AES-256 for symmetric encryption of data at rest
• RSA-4096 / ECDSA P-384 for asymmetric operations and digital signatures
• TLS 1.3 for all data in transit — TLS 1.0 and 1.1 explicitly disabled
• Argon2id / bcrypt for password hashing — no plaintext storage under any circumstance
• Hardware Security Module (HSM) or cloud KMS for key storage and rotation (where scoped)

3. Access Control & Identity (Configurable)

• Role-Based Access Control (RBAC) enforced at the architecture level (available upon scope)
• Multi-Factor Authentication (MFA) required for all administrative and remote access (available upon scope)
• Privileged Access Management (PAM) for all system-level credentials (available upon scope)
• NIST SP 800-207 Zero-Trust architecture — no implicit trust based on network location (available upon scope)
• Regular access reviews with automatic deprovisioning of inactive accounts (available upon scope)

4. Secure Development Lifecycle (SDLC)

We follow NIST SP 800-218 (SSDF) practices across all development engagements:

• Threat modeling performed at the architecture phase before code is written (available upon scope)
• Static Application Security Testing (SAST) integrated into every build pipeline (available upon scope)
• Dependency vulnerability scanning (CVE-based) on all third-party libraries (available upon scope)
• Software Bill of Materials (SBOM) generated for every deliverable (available upon scope)
• Peer code review with security checklist for all production-bound code (standard practice)
• Penetration testing available as an independent third-party service (available at additional cost)

5. Monitoring & Incident Response (Optional)

• Immutable audit logs retained for a minimum of 365 days (available upon scope)
• Real-time intrusion detection system (IDS) deployment available (available upon scope)
• Endpoint Detection & Response (EDR) integration on supported environments (available upon scope)
• SIEM integration for centralized log aggregation and anomaly alerting (available upon scope)
• Documented Incident Response Plan (IRP) provided with all security engagements (available upon scope)
• Security incident notification to client within 24 hours of confirmed breach detection (available upon scope)

6. Supply Chain Security (Optional)

• SBOM generated and delivered with all software projects (available upon scope)
• All third-party dependencies vetted for known CVEs prior to integration (available upon scope)
• No foreign-controlled or unsourced components introduced without client approval (standard practice)
• Vendor security assessments conducted for any tools introduced to client environments (available upon scope)

7. Website Security (This Site)

• Content Security Policy (CSP) — blocking unauthorized scripts and resources
• X-Frame-Options: DENY — preventing clickjacking via iframe embedding
• X-Content-Type-Options: nosniff — preventing MIME-type sniffing attacks
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy: camera, microphone, and geolocation disabled
• Honeypot field and rate limiting (3 submissions / 10 minutes) on contact form
• All form inputs sanitized server-side and client-side before processing
• No tracking cookies, no advertising networks, no analytics third parties

8. Vulnerability Disclosure

If you discover a security vulnerability in our website or any Darkbloom Industries™ deliverable, we encourage responsible disclosure. Please use our contact form with the subject "Security Disclosure" and a brief description. We will acknowledge receipt within 48 hours and respond with a remediation timeline. We request that you do not publicly disclose the vulnerability until a fix has been deployed.

9. Scope & Pricing Considerations

Security is not a one-size-fits-all solution. Each project is unique, and security controls are implemented based on:

• Project Scale: Larger, enterprise-level projects require more comprehensive security controls
• Compliance Requirements: Specific regulatory frameworks dictate required controls
• Budget: Security implementation costs scale with the complexity and depth of controls required
• Threat Model: Projects handling sensitive data require enhanced protections
• Client Preferences: We work with each client to determine the appropriate security posture

10. Limitations

Darkbloom Industries™ does not currently hold a Facility Clearance (FCL) or operate a SCIF. We do not accept classified work under SAP/SAR programs at this time. We will always be transparent about our current capabilities and will never overstate our credentials or compliance status.

11. Contact

For security inquiries, compliance consultations, vulnerability disclosures, or to request a Capabilities Statement, please use our secure contact form:

CONTACT US ▶