30 days to remediate.That's the PCI-DSS 4.0 clock.
PCI-DSS 4.0 Req 6.2 requires secure coding practices including automated scanning for all in-scope payment systems. Issue vulnerabilities is only half the requirement.
- Source: PCI Security Standards Council, PCI-DSS v4.0, Requirement 6.2 (March 2022).
The scanner surfaces it, the sprint backlog holds it
You have 30 days to resolve critical payment vulnerabilities.
PCI-DSS 4.0 Req 6.3.3 requires all payment system software to be protected from known vulnerabilities. Req 6.4 specifies critical vulnerabilities must be remediated within one month of discovery. When issues queue behind sprint cycles, that clock runs whether or not a ticket has been picked up.
PCI-DSS v4.0, Requirements 6.3.3 and 6.4 (PCI Security Standards Council, 2022)Magecart averages 200 days on a checkout page before detection.
PCI-DSS 4.0 Req 6.4.3 requires every script on a payment page to be authorized, inventoried, and integrity-verified with Subresource Integrity hashes. Magecart attacks compromise analytics, chat, and recommendation scripts loaded on checkout pages. The average dwell time before detection is 200-300 days.
Req 6.4.3: PCI-DSS v4.0 (PCI SSC, 2022). Dwell time: Recorded Future, Magecart Threat Intelligence Report, 2023.Every payment code change needs a documented approval trail.
SOX IT General Controls require segregation of duties and documented change management for all systems affecting financial reporting. PCI-DSS 4.0 Req 6.5 requires change and tamper-detection mechanisms on payment pages checked at least weekly. Manual PR review with no structured evidence trail fails both.
SOX Section 404; PCI-DSS v4.0, Req 6.5 (PCI SSC, 2022).PCI-DSS 4.0 compliance at the code level, not just the process level
30-day remediation window
- Hyrax executes changes autonomously. Issues don't wait for sprint allocation.
- Every change is a PR with full attribution: issue, resolve, test results, merge timestamp.
- Continuous scanning means issues surface on day 1, not at quarterly review.
Payment page script integrity
- Scanner patterns enforce SRI hash requirements on external scripts loaded in payment flows.
- Deterministic patterns detect missing Content-Security-Policy headers and unauthorized script sources.
- Scans run continuously. A new script added without authorization surfaces immediately, not 200 days later.
Change management evidence
- Every Hyrax upgrade is a PR linked to its issue: issue ID, upgrade diff, test suite results, approval, merge.
- Hyrax produces a complete, timestamped audit trail for every autonomous change to in-scope code.
- Segregation of duties: Hyrax opens the PR; a human approves and merges. Requester and approver are always different.
What PCI-DSS 4.0 requires at the code level
| Requirement | What it mandates | Hyrax |
|---|---|---|
| Req 6.2 | Secure coding practices including SAST for all in-scope payment systems | Continuous SAST-grade scanning with autonomous upgrade execution |
| Req 6.3.3 | All software protected from known vulnerabilities | Deterministic vulnerability scanner with PR-based remediation |
| Req 6.4 | Critical vulnerabilities remediated within 1 month | Issues surface immediately and arrive as pull requests without a sprint queue |
| Req 6.4.3 | All payment page scripts authorized, inventoried, SRI-verified | Continuous scanning verifies SRI requirements on every change |
| Req 6.5 | Change and tamper-detection on payment pages, checked weekly | Continuous scanning; every change produces an audit-linked PR |
Source: PCI Security Standards Council, PCI-DSS v4.0, March 2022.
Common questions
from fintech security teams
Does Hyrax satisfy the SAST requirement in PCI-DSS 4.0 Req 6.2?
Hyrax's Audit workflow runs multi-agent scanning across in-scope payment code. SAST-grade coverage includes security vulnerabilities, injection patterns, and convention violations. It produces issues and closes them autonomously. Whether it satisfies your QSA's specific interpretation of Req 6.2 depends on your assessment scope. Review the output with your QSA before the assessment window.
How does Hyrax produce audit evidence for PCI-DSS assessments?
Every issue Hyrax surfaces and every change it executes is logged as a PR with a complete audit trail: issue type, severity, code diff, test results, approver, merge timestamp. This produces the change management documentation Req 6.5 requires without any additional tooling.
We have a Snyk or SonarQube scan in CI/CD already. What does Hyrax add?
Snyk and SonarQube surface vulnerabilities. The issue goes into a queue. Hyrax closes the queue: autonomous upgrade execution, 13-step verification before merge, Linear ticket lifecycle closure. The scanner is the detection layer; Hyrax is the remediation layer.
Can Hyrax help with SOX change management requirements?
Yes. SOX IT General Controls require documented change requests, approval from both business and technical stakeholders, segregation of duties, and deployment audit logs. Every Hyrax upgrade is a PR. It cannot self-merge. The developer or lead who merges it is the approving party. The issue, upgrade, and merge event are all logged.
What payment code languages does Hyrax support?
Hyrax supports JavaScript, TypeScript, Python, Go, Ruby, and Java. PCI-DSS in-scope frontend code (checkout pages, payment forms) in JavaScript/TypeScript is fully supported.