A First-Attempt CASA Tier 2 Clearance: Security Built Into the Pipeline, Not Bolted On
Sachin Jain
Apr 24, 2026
Security assessments have a reputation for going sideways. A developer submits their app, the assessor comes back with a list of findings, the team scrambles to fix things, and the whole cycle starts again. Weeks slip by. Launches get delayed. Budgets stretch.
That is not what happened here.
When one of our clients needed to pass a CASA Tier 2 security assessment to unlock restricted Google OAuth scopes for their Workspace-integrated application, we made a deliberate choice: treat security as an engineering discipline built into the delivery pipeline, not a compliance checkbox at the end.
The result was a 9.7 out of 10 on the first attempt — no rescan cycles, no launch delays, and a clean path to Google API approval.
This post walks through exactly how we did it, what CASA and DAST actually mean in practice, and what engineering teams can take away from this engagement.
First, Let’s Establish What We’re Actually Talking About
Before getting into the mechanics of this engagement, it’s worth grounding the terminology. The terms CASA, DAST, and ASVS get used loosely, and the differences matter.
The key thing to understand about CASA is that it is not just a box to check. It is a structured evaluation against a well-defined set of controls — one that covers authentication, session management, API security, data exposure, header configuration, and more. Teams that go into a CASA assessment without preparation tend to find out the hard way that there are more failure points than they expected.
The Challenge Security on the Critical Path
The client was building a Next.js application that integrated with Google Workspace APIs. To access the restricted OAuth scopes they needed, Google’s review process required two things to happen in sequence:
- Pass a CASA Tier 2 DAST assessment through an authorized lab (TAC Security, in this case)
- Submit the results for Google’s OAuth app review
Both processes have wait times. Google OAuth review typically takes one to three weeks. The lab assessment itself takes another one to three weeks. And any failed findings that require a rescan add another full cycle on top of that.
With a real product roadmap and a launch window on the line, the team could not afford to burn three to six weeks on remediation loops.
Treating security as an end-of-pipeline audit was not an option. It had to be wired into the build from the beginning.
Our Approach Security Gates in the Deployment Pipeline
Rather than preparing for compliance after the application was built, we integrated security enforcement directly into the development workflow. The mechanism for this was a Claude Code skill we built called /casa-verify.
This skill functions as a structured set of automated security gates, triggered through our /promote-branch workflow. No code reaches the development environment without first passing these checks.
The /casa-verify skill enforced 32 controls in total. Of those, 27 were fully automated. The remaining controls required targeted manual validation, particularly around Google API integration behavior.
Here is what the automated gates checked on every deployment:
- Build integrity: Clean TypeScript compilation with zero tolerance for build errors. An application that compiles with suppressed warnings is an application hiding problems.
- Unsafe function elimination: Flagged and blocked any use of
eval()ornew Function(). These patterns open the door to code injection and are explicitly called out in ASVS. - Insecure rendering patterns: Prevented rendering patterns in application routes that could expose the app to cross-site scripting or similar injection attacks.
- Security headers: Enforced mandatory presence of Content-Security-Policy, HSTS, X-Frame-Options, and X-Content-Type-Options on every response. Missing or misconfigured headers are among the most commonly flagged issues in DAST assessments.
- Framework exposure suppression: Blocked the
X-Powered-Byheader, which would have revealed the Next.js version to potential attackers — a finding we confirmed in our first internal scan. - Dependency hygiene: Zero tolerance for high or critical vulnerabilities in third-party packages, evaluated on every build.
- Authentication enforcement: Verified that authentication was enforced across all API routes. An unprotected endpoint in a Google Workspace app is a critical-level finding.
- Hardcoded secrets detection: Scanned for API keys, tokens, or credentials committed to the codebase.
This is the kind of control set that security teams typically apply manually during periodic reviews. Automating it as a deployment gate means every code change is evaluated against it, not just those that coincide with a scheduled audit.
Pre-Audit Validation Four Scans Before the Assessor Arrived
Before submitting anything to the external lab, we conducted a structured series of internal DAST scans using OWASP ZAP. The goal was to surface and remediate every issue that a standard scanning tool would flag, so the external assessment could focus on what a standard tool would miss.
Run 1 (Unauthenticated scan):
Two medium-level findings surfaced immediately. The X-Powered-By header was present, exposing the Next.js version. The Content Security Policy included unsafe-eval. Both were resolved before the next scan cycle.
Disabling X-Powered-By in Next.js is a one-line configuration change. Removing unsafe-eval from the CSP required confirming it was not actually needed by any part of the application — it was not, so the directive came out cleanly.
Run 2 (Verification):
Both fixes confirmed as resolved.
Run 3 (Authenticated scan across 54 URLs):
The deeper authenticated scan identified three additional medium-level findings – all related to incomplete Content Security Policy directives. Specifically, form-action, base-uri, and object-src were missing.
This is a subtle but important point worth understanding.
Run 3 also returned a handful of informational findings: session cookie detection, user-agent fuzzing, and cache-control behavior on static pages. These are expected outputs from a thorough DAST scan of any Next.js application, and none of them represented actual vulnerabilities.
Run 4 (Final verification): All previously identified findings confirmed as resolved.
By the time the external assessor began their work, the application had already been through four scan cycles. Every finding that a standard DAST tool would produce has been addressed. The assessment could now focus on what sits above the automated baseline.
What Our Internal Scans Missed
This is the part of the engagement that is worth being honest about because it speaks to why external assessments matter even after thorough internal validation.
The external assessment by TAC Security identified one genuine gap: the application was missing the Cross-Origin-Resource-Policy (CORP) header.
Handling False Positives Infrastructure Context Matters
The assessment also surfaced a cluster of findings related to the client’s domain setup. The application was hosted on Google Cloud Run, with the primary domain routed through GoDaddy’s forwarding infrastructure. The scanner observed responses from the redirect layer before traffic reached the application — and flagged them.
Those findings included proxy disclosure, server header exposure, and missing HSTS on redirect endpoints.
The application itself had all the required security headers correctly configured. The scanner was not looking at the application — it was looking at the redirect layer managed by a third-party DNS and domain provider. These were infrastructure-level behaviors outside the application’s control.
We prepared detailed documentation mapping each of these findings to the specific infrastructure component responsible for it. The request flow from the public domain through the GoDaddy redirect layer to Cloud Run was traced step by step. The assessor reviewed the explanation, agreed with the classification, and marked these findings accordingly.
No remediation was needed. Clear thinking and solid documentation handled it.
The Result 9.7 on the First Attempt
When the assessment closed:
- All genuine vulnerabilities had been remediated before the external scan began
- The CORP header gap was fixed before responding to the assessment report
- Infrastructure-related false positives were classified as accepted risks with documented justification
- No rescan cycles were required
- The Google OAuth review process was not delayed
- The product launched on schedule
The score of 9.7 reflects something specific: it is not a perfect score, and that is informative. The 0.3 delta accounts for the infrastructure findings that were marked as accepted risks rather than technically remediated. The application’s security posture was excellent. The domain forwarding setup introduces some caveats that are acknowledged and documented.
That is an honest security result, not a manufactured one.
Ready to Pass Your Security Assessment the First Time?
Security compliance built into your pipeline — not bolted on at the end
BuzzClan helps engineering teams integrate automated security validation into their CI/CD workflows, conduct structured pre-audit testing, and navigate compliance-driven assessments with confidence. Whether you’re preparing for a CASA Tier 2 evaluation, a SOC 2 audit, or another security compliance requirement, our approach reduces rescan cycles and keeps your product on schedule.
What This Means for How You Should Think About Compliance Assessments
There is a broader pattern here that applies well beyond this specific engagement.
Most teams experience compliance-driven security assessments as external events — something that happens to the product rather than something built into it. The assessor shows up, findings come back, and the team responds. If there are many findings, the process repeats. Each cycle costs time and money, and in cases like this one, costs a launch window.
The shift we made — and that we now apply across client engagements — is to treat the assessment as a validation of ongoing practices rather than an audit of a finished product. When security controls are continuously enforced throughout development, the external assessor is confirming what you already know. The findings they add on top are the genuinely valuable ones: the gaps in tooling, the infrastructure ambiguities, the edge cases that only an independent set of eyes would catch.
Our quality assurance practice approaches security testing the same way it approaches functional testing — as a continuous process woven into delivery, not a gate applied at the end.
This also connects to how we think about application architecture decisions more broadly. Security posture is not independent of architectural choices. How headers are managed, how authentication is enforced, how dependencies are tracked — these are architectural decisions that determine how easy or hard it is to maintain compliance at scale.
For teams building on cloud infrastructure, our cloud security guidance covers the foundational controls that apply across deployment environments, including header configuration and authentication patterns that recur in DAST assessments.
The Technical Validation Framework We Use
The /casa-verify approach we built for this engagement is now part of our standard delivery model for secure application development. The framework has three stages:
Stage 1
Continuous automated enforcement. Security gates run on every branch promotion. The 27 automated controls in the ASVS Level 1 set are evaluated on every deployment. No code ships without passing them.
Stage 2
Structured pre-audit validation. Before any external assessment, we run multiple internal DAST scans — unauthenticated and authenticated — and address every finding. The goal is to enter the external assessment with a clean baseline.
Stage 3
Informed response to external findings. When the assessor returns findings, we respond with technical depth. We differentiate between genuine vulnerabilities, infrastructure context issues, and DAST tool limitations. We document each case clearly.
This model reduces audit cycles, improves the application’s actual security posture, and supports faster go-to-market timelines.
Our cybersecurity services team supports clients through this process end-to-end — from pipeline integration to audit response to documentation.
A Perspective from the Field
Frequently Asked Questions
CASA Tier 2 is a security evaluation mandated by Google for applications that access restricted OAuth scopes, including sensitive Google Workspace data such as Gmail, Drive, or Calendar content. It requires a Dynamic Application Security Testing scan conducted by an authorized third-party lab. Any application requesting these scopes for broad deployment to Google users must pass this assessment before receiving OAuth approval.
DAST (Dynamic Application Security Testing) uses automated tools to probe a running application for known vulnerability patterns — misconfigured headers, injection points, exposed server information, and similar issues. Penetration testing involves a skilled human tester who combines automated tools with manual analysis, creative attack chaining, and business logic testing that tools cannot perform. DAST is faster and more scalable. Penetration testing goes deeper. CASA Tier 2 requires DAST; CASA Tier 3 requires a full penetration test.
Because several important CSP directives — form-action, base-uri, and object-src — do not inherit from default-src. If these are not explicitly defined, they are unrestricted even if the rest of the CSP is locked down. DAST tools that check CSP completeness will flag their absence as medium-level findings.
CORP is a security header that restricts cross-origin access to a resource, mitigating side-channel attacks like Spectre. It is not yet part of OWASP ZAP’s default ruleset, so many teams miss it in internal scanning. Authorized CASA labs use extended rulesets that include it. Setting Cross-Origin-Resource-Policy: same-origin is a simple configuration change that closes this gap.
The lab assessment itself typically takes one to three weeks. Google’s subsequent OAuth app review adds another one to three weeks. Any failed findings that require a rescan add another full assessment cycle. Teams that prepare properly — with internal DAST scans and continuous security enforcement — can significantly reduce total elapsed time by eliminating rescan cycles.
Yes. DAST scanners evaluate HTTP responses without inherently knowing which layer of the infrastructure generated them. Findings originating from CDNs, load balancers, or domain forwarding services, rather than from the application itself, can be presented to the assessor with documented technical evidence. Assessors generally have discretion to classify these as accepted risks when the explanation is clear and accurate.
OWASP ZAP (Zed Attack Proxy) is an open-source DAST tool maintained by the OWASP Foundation. It supports both automated scanning and manual testing, handles authenticated sessions, and covers a wide range of ASVS-aligned controls. Because it is the most widely used open DAST tool and aligns closely with the ASVS control set, running internal scans with ZAP is a practical way to simulate what an authorized lab will find before the formal assessment begins.
It means that security checks run automatically as part of every code promotion — not just during scheduled reviews or before release. Controls such as header validation, dependency scanning, authentication enforcement, and unsafe function detection run on every build. If a check fails, the promotion is blocked. This turns security from a periodic audit into a continuous property of the delivery process.
AI-assisted tooling — including the Claude Code skill we built for this engagement — can automate the evaluation of dozens of security controls on every deployment, execute structured validation workflows, and surface findings at the moment code changes rather than weeks later. This shifts the security workload from audit-and-remediate to prevent-and-verify, which is faster, cheaper, and more effective.
CASA Tier 2 maps primarily to ASVS Level 1 controls, the most critical baseline controls, which are well-suited for automated verification. Some controls at Level 2 may also be included depending on the specific application and data types handled. Understanding which ASVS level applies helps teams prioritize the implementation of controls and avoid over-engineering their compliance program.
First, triage the findings by category: genuine application vulnerabilities, infrastructure context issues, and potential false positives. Fix the genuine vulnerabilities and implement them in the deployment pipeline so they are continuously enforced going forward. For infrastructure findings, prepare documented evidence of the full request flow and present it to the assessor, accompanied by clear technical justification. Then request a rescan. Teams that prepare well for the initial assessment typically have far fewer items in this triage list.
Get In Touch
Follow Us
