This document is containd's public vulnerability disclosure policy (VDP) and coordinated disclosure process.

Machine-readable discovery:

• /.well-known/security.txt when served from the appliance UI
• ui/public/.well-known/security.txt in the repository

The .well-known segment is the literal standards-defined URL path for these files. This repository stores them under ui/public/.well-known/... so shipped UI builds serve the same /.well-known/... paths at runtime.

Do not open a public GitHub issue for security vulnerabilities.

Primary contact:

• Email: tony@defendics.com

Please include:

1. A clear description of the issue and why you believe it is security-relevant.
2. Affected versions, deployment mode, and whether the finding requires non-default configuration.
3. Reproduction steps, proof of concept, logs, screenshots, or packet captures as appropriate.
4. Any suggested mitigation or fix if you have one.

The containd project supports good-faith security research carried out in line with this policy.

If you:

• avoid privacy violations, data destruction, and service interruption;
• avoid accessing accounts or data that do not belong to you;
• make a good-faith effort to avoid unnecessary harm;
• report the issue promptly and give the project a reasonable opportunity to investigate and mitigate it;
• do not publicly disclose exploit details before coordinated disclosure is agreed;

then the project will not recommend or pursue legal action solely for that research activity.

This safe-harbor statement applies to research intended to improve the security of containd and does not excuse unlawful behavior, destructive testing, or actions that exceed the bounds above.

What to expect from the project:

• acknowledgment of receipt within 48 hours
• initial triage within 5 business days
• follow-up on severity, scope, and likely remediation path after triage
• coordination before public disclosure for confirmed vulnerabilities

Project goals for disclosure:

• fix or mitigate confirmed vulnerabilities as quickly as practical
• publish release notes and advisories clearly enough for operators to understand impact
• credit the reporter unless the reporter prefers to remain anonymous

The exact publication timeline depends on severity, exploitability, release readiness, and whether users need mitigation guidance before a full fix ships.

The following are in scope:

• the containd Go binary and packaged runtime behavior
• the containd Docker images and release artifacts
• the management API, web UI, SSH console, and CLI
• authentication, authorization, session management, and secrets handling
• config lifecycle, backup/export handling, and redaction behavior
• network enforcement, nftables programming, NAT, routing, conntrack visibility, and related policy application
• logging, audit, event export, and security-relevant telemetry generated by containd

The following are generally out of scope unless containd's integration is the root cause:

• vulnerabilities in third-party software with independent security processes, such as Envoy, Nginx, Unbound, OpenVPN, or ClamAV
• denial of service against disposable lab deployments running with intentionally weak defaults
• findings that depend entirely on a user leaving the documented bootstrap credential unchanged after first login
• social engineering, phishing, physical attacks, or compromise of systems not controlled by this project

If a finding involves an upstream dependency, reporting it to the upstream maintainer is still appropriate. Please also notify containd so the project can track and ship an updated dependency.

Permitted testing should be limited to systems, data, and accounts you own or are explicitly authorized to test.

Please do not:

• access, modify, or delete data that is not yours
• intentionally degrade availability for shared or public systems
• use high-volume automated scanning against systems you do not control
• pivot from a containd finding into unrelated infrastructure or third-party services

For classroom and local-lab deployments, reproductions against your own containerized environment are preferred.

When the project publishes a security fix, the preferred public artifacts are:

• a GitHub release with clear release notes
• a GitHub Security Advisory when appropriate
• a CVE record when appropriate and available
• a CSAF document when the issue warrants a machine-readable advisory record

Project goals for advisories and CVE publication:

• describe the affected versions and fixed versions clearly
• include mitigation guidance when a fix is not immediately available
• include root-cause information such as CWE when practical
• keep changelog, advisory text, and release notes aligned

Machine-readable publication points:

• /.well-known/security.txt
• /.well-known/csaf/provider-metadata.json
• security/csaf/advisories/ in the repository for published CSAF documents when real vulnerability advisories exist

Current CSAF posture:

• containd publishes CSAF provider metadata today
• the repository includes CSAF authoring templates and the advisory output directory
• no published CSAF advisory JSON documents exist yet because the project has not issued a vulnerability advisory that warrants one

The presence of CVEs is not treated as a failure by itself. The project cares more about root-cause reduction, clarity, and remediation quality than raw counts.

containd is intended to help operators gather evidence when something goes wrong. Relevant built-in capabilities include:

• audit logs for administrative actions
• events from services and dataplane components
• firewall and DPI telemetry
• syslog forwarding and event export
• Prometheus metrics for operational monitoring

Operators should still decide how long to retain logs and where to forward them. For stronger deployments:

• forward logs/events off-box
• preserve audit and event data during upgrades
• document retention expectations for your environment

For production-style deployments and serious training environments:

• set a unique CONTAIND_JWT_SECRET
• change the bootstrap password immediately on first login
• enable app-based MFA for administrative accounts when practical, and use the admin-side MFA requirement control for accounts that should not remain password-only
• prefer HTTPS and restrict plain HTTP where possible
• use SSH keys and disable SSH password auth when feasible
• keep CONTAIND_LAB_MODE=0
• review and minimize policy exceptions from the default-deny posture
• stay on a supported release line and apply security releases promptly

Fresh local-account installs still use a predictable bootstrap credential that must be changed on first login.

Project rationale:

• containd is frequently deployed in offline classroom, lab, and demo environments where first-access reliability matters
• the product already enforces password change on first login
• containd now supports optional app-based TOTP MFA for local accounts; stronger external auth and richer role management remain on the roadmap

This is a documented caveat, not a hidden one.