PCI DSS security checks, required before the merge
Codacy evaluates every pull request against the security thresholds you configure, and records the result. Requirement 6 asks for secure coding rules, automated checks before release, and changes assessed before deployment. Continuous delivery keeps moving.
Talk to an expert
Trusted by 15,000+ organizations and 200,000+ developers worldwide
How Codacy supports
PCI DSS compliance evidence
Software developed according to industry standards and secure coding guidelines
Configure a coding standard once and Codacy applies it to supported code across your repositories. Default standards are assigned automatically to newly connected repositories, so scope doesn’t drift as your team adds services.
Code reviewed before release to identify vulnerabilities, using manual review or automated tools
Pull request analysis checks every proposed change for supported security weaknesses and presents the findings against that change. Automated analysis covers the tooling side of this requirement.
Engineering techniques that address injection, cryptographic misuse, authentication and authorization flaws, and similar classes
Security analysis identifies supported injection patterns, insecure cryptographic patterns, and authentication and authorization weaknesses. Dynamic scanning tests configured applications and APIs. Coverage depends on language, tool and configuration.
Security vulnerabilities identified and assigned a risk ranking
Dependencies are rescanned daily, so newly disclosed vulnerabilities surface between commits. Findings carry technical severity; the risk ranking specific to your environment remains yours to assign.
Inventory of bespoke, custom and third-party software components maintained for vulnerability and patch management
A dependencies inventory across your repositories, with version and repository views so you can locate which services use an affected component version. This contributes component data to your wider software inventory rather than replacing it.
Patches and updates applied within a timeframe set by your risk analysis
Configurable deadlines per finding, with overdue status. This supports scheduling and follow-up; it does not evidence that a patch was installed.
Changes to systems and software evaluated before they are released
Quality gates evaluate each pull request against your configured issue and security thresholds and post a status check. Gate policies apply the same thresholds across every connected repository.
Regular internal and external penetration testing, with findings corrected and retested
Available as a partner engagement through WorkNest Secure, with findings and retest outcomes tracked in Codacy.
“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
PCI DSS Requirement 6
evidence for engineering leaders
Connect your Git organisation in two clicks. First evidence report the same day.
The check that runs before every merge
Set the issue and security thresholds a pull request has to meet, and Codacy evaluates every change against them and posts the result as a status check. Gate policies push the same thresholds across every repository, so a new service inherits the standard instead of waiting for someone to remember it. Configure the check as required in your Git provider and a failing gate holds the merge.
Security findings on every change
Every proposed change is checked for supported security weaknesses, with findings shown against the change that introduced them. 6.2.3 allows automated tools for this. Automated analysis runs on all of it, not the portion a reviewer had time for.
Component inventory, rescanned daily
See which components you depend on across every repository, at which versions, and which repositories use an affected version. Rescanned daily, so a vulnerability disclosed today surfaces today rather than at the next code change.
SAST on every commit
Injection patterns, insecure cryptography, and authentication and authorization weaknesses, identified before merge.
DAST for apps and APIs
Test configured running applications and APIs for weaknesses, triggered from your pipeline.
Standards applied automatically
Newly connected repositories are assigned your default coding standard, so coverage keeps pace with new services.
Severity-ranked findings
Findings arrive with technical severity attached, so the queue is ordered before anyone triages it.
Deadlines and overdue status
Set a deadline per finding to match your risk-based timeline, and see what has gone overdue.
Audit log of setting changes
Selected configuration changes in Codacy are recorded, so you can show which thresholds changed and when.
Frequently asked questions
How does Codacy support PCI DSS Requirement 6?
Codacy applies your configured coding standard to supported code, checks every pull request for security weaknesses, and evaluates changes against your thresholds before merge. Those results support your Requirement 6 evidence alongside your development policies, approvals and deployment controls.
Does automated analysis satisfy 6.2.3 on its own?
It covers the automated-tool option in 6.2.3. It does not cover the parts of 6.2.3.1 that apply to manual review — reviewer independence from the author and management approval of the change. Those stay in your process. Codacy makes the findings and check results available for that review.
Can Codacy block a change that fails a check?
Codacy posts a status check. Whether that check prevents a merge depends on your Git provider’s branch protection settings, with the Codacy check configured as required.
“Codacy has improved communication between security and development teams, and it’s continuing to raise the bar for compliance.”
David Morton Manager of Security Operations at Genesys
Assessment or QSA
review coming up?
Bring your current review process or the questions you are trying to answer. Talk to our team about:
- The repositories and languages you need to cover
- The thresholds you want every change to meet before it merges
- The records you need to produce for Requirement 6