I take security seriously and appreciate responsible disclosure of vulnerabilities in any of my projects.

If you discover a security issue, please report it through one of the following channels:

• GitHub Security Advisories: Use GitHub's private vulnerability reporting for this repository
• Email: See the repository README for maintainer contact information (if available)

A helpful vulnerability report includes:

• Description: Clear explanation of the security issue and its potential impact
• Affected versions: Specific versions, branches, or components affected
• Attack vector: How the vulnerability could be exploited
• Proof of Concept (PoC): Reproducible steps or code demonstrating the vulnerability
• Impact assessment: Potential consequences for users, data, or infrastructure
• Proposed remediation: Suggested fixes or mitigation strategies (optional but appreciated)

Please do not disclose vulnerability details in public issues, pull requests, or discussions until we've coordinated disclosure.

The following are generally outside the scope of this security program:

• Vulnerabilities in third-party dependencies (report to upstream maintainers)
• Social engineering attacks
• Physical security issues
• Denial-of-service attacks without demonstrable impact
• Issues in unsupported or deprecated versions
• Theoretical vulnerabilities without proof of exploitability

If you're unsure whether an issue qualifies, please report it and I'll make the determination.

I follow a Coordinated Vulnerability Disclosure (CVD) approach that balances transparency with responsible handling of security issues.

When you report a vulnerability, you can expect:

• Acknowledgment within 72 hours: Initial response confirming receipt of your report
• Status updates: Regular communication on remediation progress
• Collaborative remediation: Opportunity to contribute patches or validation testing
• Public recognition: Credit in security advisories (unless you prefer anonymity)
• Safe harbor: No legal action for good-faith security research

Accelerated disclosure: For critical vulnerabilities actively exploited in the wild, I may expedite the timeline with mutual agreement.

Extended disclosure: If additional time beyond 90 days is needed, I'll communicate this and provide regular progress updates.

Early disclosure: I may disclose earlier than 90 days if a patch is available and stable, with your agreement.

For eligible vulnerabilities, I will request CVE assignment through the GitHub Security Advisory system or MITRE directly. CVE publication is coordinated with the public disclosure schedule.

Security updates are provided for the following versions:

Specific projects may have different version support policies—check the repository documentation for details.

My projects aim to follow security best practices aligned with:

• OWASP Top 10
• OpenSSF Best Practices
• NIST Cybersecurity Framework
• GitHub's recommended security configurations

Where applicable, repositories implement:

• Branch protection: Required reviews and status checks on main branches
• Secret scanning: Automated detection of exposed credentials
• Dependency scanning: Automated vulnerability alerts via Dependabot
• Code scanning: Static analysis for security vulnerabilities
• Signed commits: Verified commits on protected branches
• Dependency updates: Regular automated updates for security fixes

If a confirmed security incident affects users:

1. Immediate containment and remediation
2. Impact assessment
3. Private notification to affected parties (if applicable)
4. Patch release
5. Public security advisory with timeline, impact, and remediation steps

I am committed to protecting security researchers who report vulnerabilities in good faith. I will not pursue legal action against researchers who:

• Report vulnerabilities responsibly through designated channels
• Avoid intentional harm to users, data, or infrastructure
• Do not publicly disclose vulnerabilities before coordinated disclosure
• Respect user privacy and data confidentiality
• Comply with applicable laws during security research

I encourage security research that helps improve the safety and security of these projects.

• Never commit credentials, API keys, or sensitive data to repositories
• Use environment variables or GitHub Secrets for configuration
• Include security considerations in pull request descriptions
• Run security scanners locally before submitting pull requests
• Sign commits with GPG or SSH keys when possible

As of the v1.1 release, ContextSynapse includes the following security enhancements:

• User ID Sanitization: All user identifiers are sanitized to prevent directory traversal attacks (e.g., ../ or absolute paths)
• Feedback Parameter Validation: Empty strings are rejected in feedback operations

• HTTP Status Validation: API clients validate HTTP 200 status codes before processing responses
• Timeout Configuration: 30-second timeout prevents hung connections
• No Response Caching: URLSession configured to disable caching of API responses

• Explicit Error Logging: Replaced silent try? failures with proper error handling and logging to stderr
• File Operation Safety: All file I/O operations use atomic writes and proper error reporting

• No Force Unwrapping: Eliminated unsafe force unwrapping in critical paths (e.g., Bayesian feedback updates)
• Memory Management: Replaced shared URLSession with configured instances to prevent memory leaks

If you discover a vulnerability in a third-party dependency:

1. Report it to the upstream maintainer first
2. If the dependency is unmaintained, report it here so I can evaluate migration options

Official release artifacts are published only through GitHub Releases for this repository.

Before using a release artifact, verify all of the following:

1. The artifact was downloaded from the repository's GitHub Releases page.
2. The artifact version matches the release tag you intended to install.
3. The artifact checksum matches the corresponding entry in SHA256SUMS.txt.
4. If an SPDX SBOM is attached, its version and package identity match the release.
5. If a macOS app artifact is present, it should be signed with the expected Developer ID identity and, for production releases, notarized and stapled.

Supported integrity checks include:

• SHA-256 verification against SHA256SUMS.txt
• inspection of the attached SPDX SBOM
• standard macOS signature verification tools for app artifacts, such as codesign and spctl
• GitHub release metadata review to confirm asset provenance and tag alignment

For release candidates or dry-run builds, unsigned workflow artifacts may exist inside GitHub Actions for validation purposes. Those are not production releases.

For production macOS app releases, signing and notarization are part of the expected trust model. If a published app artifact is not signed or notarized as documented, treat that release as suspect and report it.

If provenance attestations are introduced for this repository in the future, they will apply to published release assets and will be documented here.

Security reports are appropriate when they involve:

• tampered release artifacts
• mismatched checksums that cannot be explained by a documented correction
• invalid or missing expected signing/notarization on a production app release
• release pipeline behavior that could enable unauthorized publication or artifact substitution
• reproducible supply chain integrity weaknesses affecting distributed artifacts

Please report suspected security issues privately using the repository's security reporting channel. Do not publish exploit details, stolen credentials, or release-tampering claims publicly before maintainers have had a reasonable chance to investigate and respond.

The following are generally not security reports by themselves:

• requests for custom packaging formats
• unsigned dry-run workflow artifacts that were never published as production releases
• confusion about local build steps when no official release artifact is involved
• stale documentation that does not create an actual integrity, signing, or distribution risk
• feature requests for additional verification methods or package ecosystems

This security policy is reviewed periodically and updated as needed. Material changes will be announced through GitHub Security Advisories or repository releases.

Version history is maintained in the repository commit history.

Document Information

• Last Updated: March 21, 2026
• Effective Date: February 1, 2026
• Next Review: June 21, 2026