Code-security tools fall into three broad kinds:
- Scanners report what they match: vulnerable packages, leaked secrets, risky code.
- Fix platforms also open pull requests that change the code.
- Cloud security platforms add cloud configuration and runtime protection.
Coroid's Security sits with the fix platforms. It reads your code and its supply chain, and turns what it confirms into pull requests your team reviews.
Lists of features look alike. What separates tools is how they answer the questions below. Each answer links to the page that shows how Coroid does it.
Questions to ask any security tool
| Question | Coroid's answer |
|---|---|
| Does it say how each finding was confirmed? | Every finding carries its evidence: an advisory match, a validated static finding, or a reproduced failure, with a verification record for one commit. What nothing independent confirmed stays Not confirmed yet: it never fails a check or notifies anyone. See Evidence. |
| When an AI model reports a vulnerability, who checks it? | A separate run, not the one that raised it, re-derives the issue from the code at that commit. For a confirmed critical or high finding the audit also writes a proof, which counts only when two runs, each with its own environment and build, both see the failure. Where the exploit can read a file or the environment, the environment decides: the proof must return a value planted for that run, and what it prints about itself does not count. See Evidence and Security audit. |
| Where do its exploit proofs run? | In an isolated environment with no route out: no internet, no outside name lookups, no credentials and no customer data. The environment checks that before the proof runs. See Proofs. |
| Does it fix what attackers use first? | Findings in CISA's Known Exploited Vulnerabilities catalogue, findings with a high EPSS score and malicious packages are marked, due within a day and fixed first, whatever their severity. A malicious package stays open until someone attests the exposed secrets were rotated. See Severity and due dates. |
| Is a fix pull request tested before it opens? | A dependency fix shows the package inventory before and after, with the vulnerable version gone. Your project's checks must pass on the pushed change before the pull request opens. See What the pull request carries. |
| Does "fixed" mean fixed where the code runs? | Fixed in code and fixed where it is deployed are kept apart. An environment counts as fixed only from a scan of the revision it runs, so a rollback reopens the finding. See Fixed in code and fixed where it runs. |
| Can a vulnerability leak before it is fixed? | Everything Coroid publishes passes the publication gate first: review comments, check results, pull requests, commit messages, notifications and exports. On a public repository, an issue that is not public appears only as a neutral line, and its fix is kept as a private fix instead of a public branch. See Disclosure. |
| Can a change silence its own check? | Scanners run with configuration Coroid builds from your settings, never from files in the change under test. A change to scanner configuration is checked under the base commit's configuration and reported as a policy change, and that binds Coroid's own fix tasks too. A secret or code rule enforces only after it passes calibration. See Protections and enforcement. |
| What can the agents that write fixes reach? | Your organization's credentials are decrypted only by Coroid's credential broker, which records every use; model keys stay with the broker, which makes the model calls itself. Agents follow your repository's instructions only as merged, so a pull request cannot give them new ones. See Provider keys, Security and deployment and AGENTS.md. |
| Who decides what merges? | People review and merge. Coroid's fixes are pull requests, never pushes to your default branch. See Fix pull requests. |
| Where is the data? | Coroid is hosted in the EU. The EU Only AI profile keeps model inference with EU-hosted providers. See Security and deployment. |
What Coroid does not cover
Coroid's Security covers your application's code and its dependencies. It does not cover:
- Cloud configuration and identity (cloud security posture management).
- Runtime threat detection in running workloads.
- Container images and infrastructure as code, beyond what the code rules see.
- Licence compliance.
A cloud security platform covers these. Their findings can reach Coroid as work through a work request, or as alerts through GitHub code scanning, which Coroid imports. See GitHub security alerts.