Security Policy

Jeff McNeely owns and maintains HoneyContainer and this policy as an individual. Version 1.1.0 is the current release and the version presently eligible for best-effort security fixes. Version 1.0.0 remains downloadable without a separate support commitment.

Scope includes the macOS application, website, download page and DMG, feedback endpoint, AWS features, documentation, and release process. Apple Container, Docker, macOS, AWS, GitHub, registries, images, and other third-party products are outside HoneyContainer's control.

A HoneyContainer flaw is caused by its own code, configuration, packaging, website, or infrastructure. A problem reproducible by using Apple Container or Docker directly should generally be reported to that runtime.

• Reports become issues in the private HoneyContainer GitHub repository and remain there until edited or deleted.
• Contact email is optional, but without it the developer cannot ask follow-up questions or provide private status updates.
• There is no dedicated security email, PGP key, attachment channel, fallback channel, or published security.txt.
• Reports are handled on a best-effort basis. There is no guaranteed acknowledgement, assessment, update, remediation, disclosure, or around-the-clock response time.
• Reproducibility, severity, complexity, third-party dependencies, availability, and the ability to prepare a safe fix affect whether and when action is taken.

Reporters are asked to keep suspected vulnerabilities private while they are investigated and, when practical, fixed. There is no fixed embargo or guaranteed remediation window. A disclosure date may be discussed when contact information is supplied.

Good-faith reports are welcome, but this policy does not promise formal legal safe harbor. Research must be limited to systems and accounts owned by the researcher or used with explicit authorization. Denial of service, destructive testing, malware, phishing, social engineering, credential theft, privacy invasion, or access to another person's data is prohibited.

This policy cannot authorize testing of or waive claims belonging to Apple, Docker, AWS, GitHub, registry providers, or another third party.

• Critical: likely unauthorized code execution or credential compromise without meaningful user authorization, compromised release infrastructure, or broad cross-user feedback compromise.
• High: significant unauthorized file access, credential exposure, privilege escalation, or reliable trust-boundary escape.
• Medium: limited security impact requiring substantial local access, unusual configuration, or significant interaction.
• Low: minor disclosure, defense-in-depth weakness, or hardening opportunity.
• Informational: expected behavior, unsupported configuration, third-party issue, documentation issue, or no demonstrated security impact.

Expected Docker-socket privileges, malicious image behavior, and harm caused solely by a user's selected command are normally documented risks rather than HoneyContainer vulnerabilities.

• HoneyContainer is not sandboxed and runs as the current macOS user. It does not request administrator privileges or install a privileged helper.
• The signed app's only entitlement is Apple Events automation, used to open commands in Terminal or iTerm2.
• It can trigger Apple Events and Local Network permission prompts. The Local Network prompt supports the AWS credential proxy.
• Apple Container operations use the local container executable. Docker uses the socket/API when available and Docker commands where required.
• Nearly all commands use executable argument arrays rather than interpolated shell strings. The known shell helpers use hardcoded commands or pass user paths positionally.

HoneyContainer validates container names, IP and MAC addresses, network CIDRs, memory and volume sizes, and Apple Container volume strings. Known gaps include Docker host-mount paths, environment and env-file entries, port range enforcement, full tag grammar, and leading-dash image references that can be interpreted as runtime options.

• HoneyContainer does not verify image signatures, enforce digests, integrate content-trust tools, or independently classify an image as trusted.
• Docker build contexts include the entire selected directory with no ignore-file filtering or size limit. Files such as .git, .env, and node_modules can be sent to the daemon.
• Build context containment does not canonicalize symlinks.
• Archive and container copy behavior is delegated to the installed runtime. HoneyContainer does not implement its own archive extractor.
• HoneyContainer does not display, create, or modify container health checks and should not be treated as a health-monitoring system.

Only named Environment sets use HoneyContainer's encryption. They are sealed with AES-256-GCM through CryptoKit using a random 256-bit key stored as a non-synchronizing Keychain item with AfterFirstUnlockThisDeviceOnly accessibility.

If the Keychain read fails or the key is deleted, HoneyContainer creates a new key. Previously encrypted Environment sets then become unreadable and can appear empty without an error or recovery path. Other UserDefaults preferences are not protected by this mechanism.

The optional AWS feature can read and edit shared AWS configuration, save profiles, assume roles, and proxy credentials. Each container launch receives a separate helper, port, random 32-byte bearer token, and read-only mounted token directory.

• Credential routes require the token, but the listener binds all interfaces and does not validate the caller's network address.
• Health and identity routes do not require the token. The identity route can expose the AWS account ID and full role or user ARN.
• Isolation depends on token possession rather than verified container identity.
• Credentials are cached in memory and refreshed through the AWS CLI when nearing expiry. The proxy token expires after 24 hours and is not rotated.
• AWS configuration, credentials, backups, and the temporary token file are not assigned explicitly restrictive permissions by HoneyContainer; existing modes and the user's umask apply.
• Static credentials are stored in plaintext in ~/.aws/credentials. HoneyContainer keeps up to five timestamped backups of both the config and credential files.

• Console logs are stored under ~/Library/Caches/io.mcneely.honeycontainer. Rotation is checked at launch when console.txt reaches 5 MiB, with up to ten files and no age-based expiry.
• Image build logs are stored per image under ~/Library/Application Support/HoneyContainer/images/. They have no general size or age limit.
• Build logs remain until overwritten, their image is deleted, orphan cleanup removes them, the in-app clear action runs, or they are manually removed.
• Dragging HoneyContainer to the Trash does not remove UserDefaults, logs, build history, temporary proxy remnants, AWS backups, or the Environment encryption key.

Removal instructions and AWS-file cautions are provided in the Privacy Policy.

• The app and DMG are signed with Developer ID Application: Jeff McNeely (4RV372T7SM).
• The release pipeline enables Hardened Runtime, verifies code signatures, notarizes the DMG through Apple, staples the ticket, validates it twice, and stops on failure.
• The download page publishes immutable versioned links, DMG sizes, and SHA-256 checksums for versions 1.1.0 and 1.0.0.
• HoneyContainer does not automatically check for, download, or install updates.
• There is no installed-copy blocking system, automated revocation system, or direct user-notification channel.

Direct dependencies include Apple Container 1.1.0, AsyncHTTPClient 1.35.0, and SwiftNIO 2.101.3 as resolved. Transitive dependencies are recorded in Package.resolved.

The release build treats Swift and C warnings as errors and performs Apple signing and notarization checks. It does not require a clean worktree, run unit tests, or verify version consistency.

No automated dependency or static security scan, secret scan, dynamic analysis, fuzzing, SBOM, reproducible-build check, CI workflow, provenance statement, or independent penetration test is configured.

• The static website is designed for Cloudflare Pages. The public DMG is served read-only from Amazon S3.
• The feedback function authenticates to GitHub with a runtime bearer token and creates issues in a private repository.
• The endpoint limits field lengths, validates report type, accepts text only, and includes a hidden spam honeypot.
• The function has no application-level rate limit, CAPTCHA, authentication, request-size check before form parsing, explicit content-type allowlist, origin enforcement, or comprehensive Markdown sanitization.
• Deployed Cloudflare headers, bot controls, account-level rate limits, and exact GitHub token permissions are controlled outside this repository and are not verified by this policy.

Incident response is best effort. There is no formal response team, guaranteed response time, notification list, around-the-clock coverage, backup responder, or succession plan. The website and release notes may be used for notices because HoneyContainer has no account system.

Known risks include the lack of sandboxing, Docker-daemon-level socket access, local runtime path substitution, validation gaps, broad build contexts, plaintext secrets in logs and AWS files, AWS proxy network exposure, runtime-managed TLS and credentials, absent health-check visibility, and no independent security review.

Publishing this policy does not create guaranteed support, remediation, disclosure, update, or continued-maintenance obligations.

Report suspected vulnerabilities through the HoneyContainer feedback form. General use remains subject to the Terms of Use.