Security Policy — Millarum

1. Security Commitment

Millarum is committed to maintaining the security of its products and protecting the environments in which they operate. We follow industry-standard security practices appropriate for the scale and nature of our products, and we are transparent about our current capabilities and limitations.

We believe in responsible, honest communication about our security posture. We do not over-commit to practices we cannot sustain, and we continuously improve our security baseline.

2. Scope

This Security Policy applies to all Millarum products and their associated codebases, including:

Millarum Roadmap — roadmap and milestone visualization app
Millarum Dashboards — dashboard analytics widgets
Supporting infrastructure: documentation websites, public marketing pages

The security controls of the underlying deployment platform are managed by the platform provider and fall outside the scope of this policy.

3. Secure Development Lifecycle

Security is considered throughout the development lifecycle of Millarum products:

Design Phase

Principle of least privilege: products request only the minimum permission scopes required to function.
No unnecessary data collection: products are designed to avoid storing data that is not required for functionality.
Input validation is applied at system boundaries.

Development Phase

Code is reviewed before merging to production branches.
Dependencies are tracked and kept up to date.
Sensitive values (tokens, secrets) are never hardcoded in source code.
Output encoding is applied to prevent injection attacks.

Deployment Phase

All communication uses encrypted transport (HTTPS/TLS).
Production deployments follow the security requirements of the deployment platform.
Access to production systems is restricted to authorized personnel only.

4. Vulnerability Management

Millarum uses Snyk (Free tier) for automated dependency vulnerability scanning. We are transparent about what this covers and what it does not.

Practice	Status	Notes
Dependency vulnerability scanning	Active	Automated via Snyk Free on code repositories
Known CVE monitoring	Active	Snyk surfaces known CVEs in project dependencies
Static Application Security Testing (SAST)	Partial	Basic code analysis via Snyk; full SAST tooling not currently in scope
Penetration testing	Not currently performed	No third-party or automated pen testing at this time
Dynamic Application Security Testing (DAST)	Not currently performed	Outside current scope
Bug bounty program	Not available	Not offered at this time; responsible disclosure is encouraged

Our current vulnerability scanning is limited to dependency analysis via Snyk Free. We do not perform comprehensive penetration testing or full SAST/DAST. We aim to expand our security testing capabilities over time.

Remediation Targets

Severity	Target Remediation
Critical (CVSS 9.0–10.0)	Within 7 days of identification
High (CVSS 7.0–8.9)	Within 30 days
Medium (CVSS 4.0–6.9)	Within 90 days or next minor release
Low (CVSS 0.1–3.9)	Addressed in roadmap planning

5. OWASP Top 10 Controls

Millarum applies controls aligned with the OWASP Top 10 web application security risks. The following describes our current posture:

OWASP Risk	Our Control
A01 — Broken Access Control	Permissions enforced by the platform; app reads only data the authenticated user has access to. No privilege escalation paths in app logic.
A02 — Cryptographic Failures	All data in transit uses HTTPS/TLS. No sensitive data is stored in client-side storage (localStorage, cookies). No custom cryptographic implementations.
A03 — Injection	User-supplied values are not concatenated into queries. Output is encoded before rendering. Platform APIs handle query construction.
A04 — Insecure Design	Least-privilege permission model by design. No unnecessary data collection. Threat modeling considered during feature design.
A05 — Security Misconfiguration	Default secure settings used. No debug endpoints exposed in production. Platform security guidelines followed for deployment configuration.
A06 — Vulnerable Components	Dependencies scanned with Snyk Free. Outdated or vulnerable packages are updated as part of the development cycle.
A07 — Identification & Authentication Failures	Authentication is delegated entirely to the host platform. Millarum products do not implement custom authentication mechanisms.
A08 — Software and Data Integrity Failures	Code is reviewed before deployment. Dependencies sourced from official package registries. Subresource Integrity (SRI) used where CDN resources are loaded.
A09 — Security Logging & Monitoring Failures	Platform-level logging is relied upon. Millarum does not maintain a separate SIEM; incidents are tracked manually at current scale.
A10 — Server-Side Request Forgery (SSRF)	No user-controlled URL fetching in app logic. All external API calls use fixed, known endpoints defined at development time.

6. Access Control & Personnel Security

Access to production systems and deployment tooling is restricted to authorized Millarum personnel only.
Access is granted on a need-to-know basis and reviewed periodically.
Multi-factor authentication (MFA) is required for access to production-related accounts and code repositories.
Personnel who no longer require access have their access revoked promptly upon role change or departure.

7. Security Incident Response

In the event of a confirmed security incident, Millarum will:

Contain — isolate affected systems or disable the affected feature to limit impact.
Assess — determine the scope, root cause, and affected users.
Notify — inform affected customers within 72 hours of confirming a breach that affects their data, in line with applicable regulations.
Remediate — apply fixes and deploy a patched version as quickly as possible.
Review — conduct a post-incident review and update controls to prevent recurrence.

Security incidents are tracked with the same severity framework as service incidents. See the Service Level Agreement for response time targets.

8. Responsible Disclosure

Millarum encourages responsible disclosure of security vulnerabilities. If you discover a potential security issue in any Millarum product, please report it to us privately before public disclosure.

How to Report

Email: contact@millarum.com
Subject line: "Security Disclosure — [brief description]"
Include: affected product, steps to reproduce, potential impact, and your contact information.

Our Commitment to Reporters

We will acknowledge your report within 5 business days.
We will keep you informed of our progress toward a fix.
We ask that you allow us a reasonable time to remediate before any public disclosure (typically 90 days).
We will credit your responsible disclosure in release notes if you wish.

We do not pursue legal action against security researchers who act in good faith and follow this responsible disclosure process.

9. Platform Security Reliance

Millarum products are deployed on and within third-party platforms. Many security controls are provided by and enforced at the platform level, including:

User authentication and session management
Data center physical security and infrastructure compliance (SOC 2, ISO 27001, etc.)
Network-level DDoS protection and firewall rules
Data residency and encryption-at-rest

Millarum relies on and complies with the security requirements and certifications of its deployment platforms. For platform-level security details, refer to the security documentation of the applicable platform provider.

10. Policy Review & Updates

This Security Policy is reviewed at least annually, or sooner in the event of a significant security incident or change in product architecture. The "Last updated" date at the top of this page reflects the most recent review.

Material changes to security practices will be communicated via product release notes. Continued use of Millarum products following an update constitutes acceptance of the revised policy.

11. Contact

For security-related questions or to report a vulnerability:

Email: contact@millarum.com
Response target: 5 business days for initial acknowledgement