Skip to content

Check code for security vulnerabilities (CWE, CERT)

Understand's CodeCheck ships security-focused standards you can run over your code to find the coding patterns behind common vulnerabilities. This guide covers picking the right standard, running it, triaging the results, and producing a report for a security review.

What CodeCheck does and doesn't do

CodeCheck is a static analyzer: it flags source patterns associated with weaknesses (a strcpy into a fixed buffer, an unchecked return, a tainted index). It does not run your code, scan binaries, or check dependency CVEs. Pair it with your build/dependency scanners for full coverage.

1. Pick a security standard

From Which standard should I check against?, the security-relevant configurations are:

  • SEI CERT C / C++ / Java — secure-coding rules. See which standard should I check against? for per-standard check counts and automated coverage.
  • MITRE CWE Top 25 — checks mapped to the most dangerous software weaknesses.
  • MISRA C / C++ — safety-oriented, but many rules eliminate undefined behavior that is also a security root cause, so security programs often run it too.
  • Bug Hunter — deep C/C++ defect checks (buffer/pointer/flow defects); see Bug Hunter.

Read the coverage % correctly

The automated-coverage column in which standard is the share of a standard's rules CodeCheck decides automatically. The rest need manual review, and a security assessment must still account for them.

2. Configure and run the check

  1. Open Checks → Select Checks and select the security standard (copy it first if you want to tailor the rule set — see run your first check).
  2. Run the inspection over the project.

3. Triage the findings

Open the Violation Browser to see, filter, and jump to each finding. Sort or filter by severity, and use the git filters (On Uncommitted Lines, In Files Modified This Week) to focus a review on new or changed code. Each CWE/CERT violation reports the rule it maps to, so you can trace a finding back to the weakness it represents.

4. Report for a security review

Generate a compliance report to show, rule by rule, what is Compliant, Not Compliant, or requires manual review — the per-rule evidence a reviewer expects, with your documented deviations. To hand findings to another security tool or a tracker (for a plan-of-action-and-milestones workflow, for example), export via SARIF — see Import SARIF from another tool for the interchange format Understand reads and writes.

5. Keep it continuous

Security regressions are cheapest to catch at the change that introduces them:

Where to next