Code security evidence for HITRUST CSF, on every pull request
Codacy analyzes every change against your configured security rules and keeps a dated record of the outcome. HITRUST names this work directly: input validation at Level 1, change control, technical vulnerabilities.
Trusted by 15,000+ organizations and 200,000+ developers worldwide
How Codacy supports
HITRUST CSF compliance evidence
Codacy produces evidence for the control references that govern how code is written, tested and merged, across Categories 06, 09 and 10. Here is where it applies.
At Level 1, that web applications are checked for the most current OWASP Top 10 vulnerabilities related to input validation, and that development follows secure coding guidelines
Input validation, injection and cross-site scripting patterns identified on the pull request that introduced them, under one rule set applied across every connected repository.
Security requirements analyzed and specified for information systems
The requirements you define that are automatically testable become rules and thresholds Codacy applies to every change.
Changes assessed before they are accepted
Every pull request is evaluated against your configured thresholds, and the outcome is recorded against the change.
A current inventory of software with versions, timely action on identified vulnerabilities, and awareness of newly disclosed ones
Component names, versions and the repositories using each, rescanned daily. Severity-based remediation deadlines, with on track, due soon and overdue status on every finding.
Controls against malicious code, including code entering through components
Known malicious packages identified in supported manifest files, using the OpenSSF Malicious Packages database.
Systems checked technically against the organization’s security implementation standards
Automated, repeatable checks against your configured rule set, with the result retained for each change and reportable across every connected repository.
“Codacy gives us a lot of detail, which is very good for us to make sure that we’re maintaining good code quality and are following a coding standard.”
Kader Kawsar Head of Software and Data Engineering
Read case study
HITRUST control evidence
for engineering leaders
Connect your Git organization. Dated analysis records start the same day.
Input validation patterns, on every pull request
10.b is a Level 1 baseline requirement, so it reaches any organization running a web application. Codacy identifies supported input validation, injection and cross-site scripting patterns on the change that introduced them, before the merge.
Malicious packages, flagged on arrival
Known malicious packages identified in supported manifest files, using the OpenSSF Malicious Packages database.
Dated records that the checks ran
Codacy’s pull request analysis history, issues metrics and usage report — dated, repeated records across every connected repository, exportable for the assessor’s sample.
The inventory 10.m asks for
Component names, versions, and the repositories using each, across every connected repository.
Daily rescans, between releases
Dependencies are rescanned daily, so a newly disclosed vulnerability surfaces at the next scan rather than the next commit.
Timely action, with a deadline
A remediation deadline per severity, and each finding’s status against it: on track, due soon or overdue.
Frequently asked questions
How does Codacy support a HITRUST CSF assessment?
Codacy produces evidence for control references in Categories 06, 09 and 10: the checks that ran on each change, the gate outcome recorded against it, and the dependency findings behind them. Certification attaches to your organization for a defined scope, and this is the code-stage evidence inside it.
Do we need this before our assessment?
Assessors scoring the Implemented maturity level look for evidence that your checks ran, repeatedly, across the assessed scope. That evidence accumulates as your team merges code, so teams typically want Codacy running for at least a full development cycle beforehand.
Can Codacy block a change that fails a check?
Yes, when Codacy status checks are configured as required checks in your Git provider. Your branch protection settings determine whether a failing check prevents a merge.
What can we export for the assessor sample?
Findings export to CSV. Analysis history, issues metrics and the usage report export to CSV and JSON, so the full population your assessor samples from sits in your own evidence store.
HITRUST e1, i1 or r2
assessment coming up?
Bring your assessment scope or the control references your assessor has already flagged. Talk to our team about:
- The repositories and languages inside your assessed scope.
- The Category 10 requirements you need code-level evidence for.
- The 10.b input validation evidence your assessor will ask to see.