Security and accessibility testing are most effective when embedded into the development workflow — not bolted on as a pre-release gate. Shift-left means testing earlier: security checks in the IDE, accessibility audits during design, and automated scans on every pull request. This lesson provides the integration strategy that makes security and accessibility a continuous practice rather than a periodic event.
Shift-Left Security and Accessibility — Continuous Integration
The shift-left approach moves testing earlier in the development lifecycle, where defects are cheapest to fix.
# Shift-left integration points
SHIFT_LEFT = [
{
"stage": "Design / Requirements",
"security": "Threat modelling: identify attack surfaces before coding",
"accessibility": "Design review: verify colour contrast, touch targets, keyboard flows in mockups",
"who": "Product + Design + QA",
},
{
"stage": "Development (IDE)",
"security": "SAST linting (SonarLint, ESLint security rules) catches issues while coding",
"accessibility": "axe-linter VS Code extension flags a11y issues in HTML/JSX as you type",
"who": "Developers",
},
{
"stage": "Pull Request",
"security": "npm audit / pip audit for dependency vulnerabilities; SAST scan",
"accessibility": "cy.checkA11y() in functional tests; automated axe scan",
"who": "CI pipeline + code reviewers",
},
{
"stage": "Post-Deployment (Staging)",
"security": "ZAP baseline scan against staging; active scan for release candidates",
"accessibility": "Manual keyboard testing; screen reader spot-check on changed pages",
"who": "QA + Security team",
},
{
"stage": "Production Monitoring",
"security": "WAF alerts, intrusion detection, vulnerability disclosure program",
"accessibility": "User feedback, support ticket analysis, periodic manual audit",
"who": "Security team + Support + QA",
},
]
# Compliance tracking metrics
COMPLIANCE_METRICS = [
{
"metric": "Security — Known vulnerabilities in dependencies",
"target": "Zero critical/high CVEs; medium CVEs tracked with fix dates",
"tool": "npm audit, Snyk, Dependabot",
},
{
"metric": "Security — ZAP findings",
"target": "Zero high-risk findings; medium tracked in backlog",
"tool": "OWASP ZAP baseline scan in CI",
},
{
"metric": "Accessibility — axe-core violations",
"target": "Zero critical/serious; moderate tracked with fix dates",
"tool": "cypress-axe, playwright-axe in CI",
},
{
"metric": "Accessibility — WCAG Level AA conformance",
"target": "Full conformance on all public-facing pages",
"tool": "Quarterly manual audit + continuous automated scanning",
},
{
"metric": "Both — Ratchet (never increase violation count)",
"target": "Each sprint fixes more violations than it introduces",
"tool": "Tracked in sprint retrospective metrics dashboard",
},
]
# Team accountability model
ACCOUNTABILITY = {
"Developers": [
"Use SAST linting in IDE for security and accessibility",
"Add data-cy attributes for testability; add ARIA attributes for accessibility",
"Fix security and a11y issues flagged in code review",
"Run axe-core locally before submitting PRs",
],
"QA / SDETs": [
"Include security payloads in input validation tests",
"Add cy.checkA11y() to every functional test",
"Perform keyboard testing during sprint testing",
"Track and report security and a11y metrics weekly",
],
"Product / Design": [
"Specify colour contrast and touch target sizes in design specs",
"Include accessibility acceptance criteria in user stories",
"Review feature files for inclusive language and clear error messages",
"Participate in accessibility design reviews",
],
}
print("Shift-Left Integration:")
for stage in SHIFT_LEFT:
print(f"\n {stage['stage']}")
print(f" Security: {stage['security']}")
print(f" Accessibility: {stage['accessibility']}")
print(f" Who: {stage['who']}")
print("\n\nTeam Accountability:")
for role, tasks in ACCOUNTABILITY.items():
print(f"\n {role}:")
for task in tasks:
print(f" - {task}")
Note: The ratchet pattern — “never increase the violation count” — is the most practical approach for teams with existing applications that have many security and accessibility issues. Instead of demanding zero violations immediately (which is overwhelming and often blocks progress), the ratchet records the current count and fails the CI build only if the count increases. Each sprint, the team fixes a few violations, lowering the ratchet threshold. Over months, the count decreases to zero without requiring a massive remediation project.
Tip: Add security and accessibility acceptance criteria to user story templates. For every story, include: “Security: no new ZAP findings; input validation prevents XSS and injection.” and “Accessibility: keyboard navigable; no new axe violations; colour contrast AA compliant.” This makes security and accessibility a definition-of-done requirement rather than an afterthought — the cheapest possible integration point.
Warning: Security and accessibility are everyone’s responsibility, but without clear accountability they become nobody’s responsibility. Assign specific roles: developers fix issues flagged by SAST and linters. QA runs automated scans and performs keyboard testing. Design ensures mockups meet contrast and target-size requirements. Without this explicit assignment, security and accessibility tasks perpetually sit in the backlog with no owner and no deadline.
Common Mistakes
Mistake 1 — Treating security and accessibility as pre-release gates only
❌ Wrong: Running ZAP and accessibility audits only before major releases — finding 200 issues with no time to fix them.
✅ Correct: Continuous integration — automated scans on every PR catch issues when there is 1 to fix, not 200.
Mistake 2 — No accountability for security and accessibility tasks
❌ Wrong: “The team should care about security and accessibility” — no specific owners, no tracked metrics, no sprint goals.
✅ Correct: Explicit role assignments, tracked metrics in retrospectives, and security/accessibility criteria in the definition of done for every user story.