CodeCordon policy
Security and data handling
A plain-language account of what happens to code submitted to CodeCordon and what a scan result can and cannot prove.
Effective July 18, 2026
How source code is processed
Uploaded zip archives and downloaded public GitHub repositories are processed on the CodeCordon server for the scan. CodeCordon does not intentionally save the archive or a complete copy of the repository after processing.
CodeCordon stores the project name, public GitHub URL when supplied, scan metadata, findings, and the source-line snippets attached to those findings. Deleting a project deletes its scans and findings from the application database.
Secrets and snippets
Finding snippets pass through a central credential redactor before storage and display. Redaction reduces accidental exposure, but users should still rotate any credential committed to source control and avoid uploading repositories they are not authorized to scan.
Language coverage
Secret and configuration patterns apply broadly to supported text files. Code-aware checks are strongest for JavaScript, TypeScript, and Python. Ruby, PHP, Go, Java, Swift, Kotlin, Vue, and Svelte receive partial pattern coverage. CodeCordon does not claim equal depth across every language or framework.
What a scan means
CodeCordon is deterministic static analysis, not a penetration test, certification, or guarantee. A clean result means no known-pattern issues were found by the rules that applied. It does not establish that an application is secure.
Public identity and contact
CodeCordon is included in OWASP's community-maintained Source Code Analysis Tools directory. Directory inclusion is not an OWASP endorsement. The distributable CLI and GitHub Action source are public. Security, abuse, and support reports can be filed through the public issue tracker.
How ShipBond checks deployments
ShipBond accepts only HTTPS production URLs. The server rejects local, private, and reserved network addresses, pins each checked request to a public DNS result, limits redirects and response size, and records only the displayed availability, metadata, and response-header evidence. These checks do not log in, submit forms, test payments, or prove the absence of runtime vulnerabilities.