Original source: Security Boulevard. This article summarises insights shared by John Maski at the inaugural AWS re:Inforce security conference in Boston (June 2019).
Background: AT&T’s DevSecOps Challenge
At AWS re:Inforce 2019—Amazon’s inaugural dedicated security conference—John Maski delivered a session titled “Integrating AppSec in your DevSecOps on AWS.” Maski spent 32 years at AT&T, most recently as Director of Production Resiliency & DevSecOps Enablement, before joining Veracode to help customers integrate application security into their delivery pipelines.
His talk addressed a challenge familiar to most large enterprises: software development optimised purely for speed, with security treated as an afterthought. At AT&T’s scale, development pipelines varied enormously across teams, skill levels were inconsistent, and there was no unified approach to application security.
Why Executive Support Is Non-Negotiable
Maski was direct on this point:
“In an organisation the size of AT&T, you can’t make meaningful progress without the support of executive leadership. It is absolutely critical to drive the necessary cultural changes.”
— John Maski, former Director, Production Resiliency & DevSecOps Enablement, AT&T
On the positive side, AT&T already had pockets of advanced CI/CD knowledge, a significant CI/CD platform under development, and—crucially—executive appetite for rapid, wide-ranging progress. That appetite provided the mandate Maski needed to connect partner organisations around a shared goal: securing AT&T’s entire application landscape. By the time he left the company, that goal was nearly complete.
Integrating Security into the CI/CD Pipeline
A core theme of Maski’s talk was that application security professionals must understand their organisation’s development tooling—not just the security tools. Speaking an engineering team’s language is prerequisite to influencing how they work.
The general model Maski described places manual processes at the two ends of the pipeline and automated testing in the middle:
- Threat modelling (start of pipeline): Still a human-driven activity. Even with tools that help visualise and document architecture, understanding system design and its attack surface requires human judgement.
- Penetration testing (end of pipeline): A final litmus test before any critical application is promoted to production. Not a replacement for earlier automated testing.
- Automated testing (throughout the pipeline): Three primary categories—Static Application Security Testing (SAST), Software Composition Analysis (SCA), and Dynamic Application Security Testing (DAST)—each targeting different vulnerability classes.
Static Application Security Testing (SAST)
SAST analyses application source code for a broad range of security flaws without executing the application. It can be integrated at two levels:
- IDE plugins: Provide real-time, in-editor feedback while developers write code. Guidance at this stage is advisory rather than mandatory, making it most effective at reducing flaws in newly written code. Veracode’s data (cited in Maski’s presentation) suggests this approach helped organisations reduce newly introduced flaws by 60 percent.
- CI pipeline: Scans triggered on code commit or pull request. Results are surfaced through the team’s ticketing system, creating a structured feedback and compliance loop. For high-security applications, Maski recommended a full-scope scan before each deployment to prevent security defects from reaching production. Teams typically run CI-triggered scans in a “sandbox” mode so that results remain within the development team before being escalated.
Software Composition Analysis (SCA)
SCA identifies known vulnerabilities in open-source libraries that the application depends on. The remediation path is almost always upgrading to a patched library version rather than modifying open-source code directly. SCA typically integrates at the same pipeline stages as SAST—IDE and CI—and feeds into the same ticketing workflows.
Dynamic Application Security Testing (DAST)
DAST interacts with a running application through an instrumented browser that crawls and audits the application from the outside—mimicking how an attacker would probe it. Unlike SAST, DAST can detect runtime and server-configuration issues that are invisible at the code level. It is typically run in the QA stage against a staging environment and, where appropriate, against the production server. Some vulnerability classes are only detectable via DAST, making it a complement to—not a substitute for—SAST and SCA.
Five Tips for Getting Traction with a DevSecOps Initiative
Drawing on his experience at AT&T, Maski offered five practical recommendations for anyone launching or scaling a DevSecOps programme:
- Partner with stakeholders. Identify and align with partners in software development early. Understand their workflows and respect their constraints. A security programme that ignores the developer experience will fail to get adoption.
- Pick the right metrics. Define what success looks like before you start. Agree on metrics with sponsors and engineering partners upfront—do not retrospectively try to prove value with numbers no one cares about.
- Don’t try to boil the ocean. Take an Agile approach. Select pilot applications, learn from the process, then expand. Document lessons at each stage and use them to improve the programme iteratively.
- Run an internal communication campaign. Raise awareness about why AppSec matters to the business. Connect application security to the company’s mission. Use internal communications as an education channel to raise the security knowledge baseline across DevOps teams.
- Demonstrate progress regularly. Report programme progress against agreed metrics to maintain executive support and budget. Tailor the reports to the audience—senior leaders need different data from engineering partners.
Three Key Learnings from AT&T’s Programme
Maski closed with three high-level takeaways from running an enterprise-scale DevSecOps programme:
- Executive leadership drives cultural change and secures budget. Without visible sponsorship from the top, security initiatives struggle to overcome organisational inertia.
- Use managed platforms to accelerate onboarding. If speed matters, choose scanning and AppSec services built on robust, maintained platforms. This lets teams focus on onboarding applications rather than building and operating scanning infrastructure from scratch.
- Build a strong team and hold a flexible plan. Map out and communicate the plan with confidence, but be prepared to learn and adjust. Setting bold goals helps drive meaningful progress even when the path changes.
Takeaways for DevOps and Security Engineers
The AT&T story demonstrates that large-scale DevSecOps transformation is achievable, but it requires more than tooling. The combination of executive mandate, developer-centric integration (meeting engineers where they work), incremental rollout, and clear metrics is what allowed AT&T to move from fragmented, speed-first development toward a consistent, security-embedded pipeline across its entire application portfolio.
For teams at any scale, the pipeline model Maski described—threat modelling, SAST in the IDE and CI, SCA, DAST in QA and production, and penetration testing before release—provides a practical template for layering security into existing delivery workflows without blocking delivery speed.