Why Application Security Needs to Shift Left

DevOpsDevOps Best Practices

YOUR COSMETIC CARE STARTS HERE

Find the Best Cosmetic Hospitals

Trusted • Curated • Easy

Looking for the right place for a cosmetic procedure? Explore top cosmetic hospitals in one place and choose with confidence.

“Small steps lead to big changes — today is a perfect day to begin.”

Explore Cosmetic Hospitals Compare hospitals, services & options quickly.

✓ Shortlist providers • ✓ Review options • ✓ Take the next step with confidence

This article is based on reporting originally published by SD Times. Quotes are attributed to industry practitioners as sourced from that piece.

The Case for Shifting Security Left

As engineering teams face mounting pressure to ship software faster, more and more aspects of the development process are being moved earlier in the lifecycle—a practice commonly called “shifting left.” Security is no exception. Because code is updated and delivered at an ever-increasing pace, treating security as a final gate before release is no longer viable.

“That’s why we profess to shift left security and basically embed it as early as possible in the development process so that developers can do a lot of the work in advance as they deliver the applications and not expect to throw it over the fence and have someone else take care of it,” said Rani Osnat, VP of Product Marketing at Aqua Security, a container security company.

Operations teams can no longer simply accept an application as delivered and then plan to secure it after deployment. The old model—where application security acted as a point-in-time governance gate before release—is increasingly incompatible with agile delivery and continuous deployment practices.

“As trends like agility, continuous delivery, or DevOps come into play, that role as a point-in-time gate and as a governance function is being questioned,” explained John Steven, Senior Director of Software Security at Synopsys.

What Top Performers Do Differently

According to Arkadiy Miteiko, co-founder and CEO of CodeAI, an AI-based security platform, the highest-performing organizations typically implement three practices in their security workflows:

  1. Inject code analysis tools into the development process and enforce fixes before deployment, rather than after.
  2. Automate attacks against pre-production code and block that code from reaching production if simulated attacks succeed.
  3. Continuously test the production environment for weaknesses in an automated, ongoing fashion rather than relying on periodic audits.

These three pillars represent a maturity model that many organizations are still working toward. The challenge is not just technical—it is also organizational and cultural.

From DevOps to DevSecOps

The logical evolution of DevOps culture is DevSecOps—a model in which security considerations are embedded alongside development and operations rather than siloed into a separate function that engages only at the end of the pipeline.

In this model, security teams retain ownership of policy definition: determining what constitutes an acceptable level of risk and what controls must be in place. However, the implementation of those policies becomes a shared responsibility between security and development teams, rather than a unilateral mandate handed down from a separate group.

“There’s a lot of automation that you can do, which again is absolutely mandatory in these environments because of the speed in which code moves in the pipeline. It is just not manageable with purely manual control,” said Osnat.

The Cybersecurity Skills Gap Makes Shift-Left Urgent

A persistent shortage of cybersecurity professionals is one of the strongest arguments for shifting security responsibility toward developers. Osnat noted that at the time of reporting, there were hundreds of thousands of unfilled cybersecurity positions in the United States alone, and industry forecasts suggested that number could climb dramatically in the following years.

“Developers are developing more applications faster and delivering code faster than security can catch up to,” said Osnat. “That’s something where really the only way to address it is not to just give more work to security, but to move some of the burden to the developers in using best practices to secure applications when they are developed. But, of course, they need to be taught and told what they are expected to do. It’s not something that you can expect them to just figure out on their own.”

There are simply far more developers in the world than security specialists. Leveraging that larger population—while equipping them with security knowledge and tooling—is a more scalable approach than trying to staff every pipeline with dedicated AppSec engineers.

The Cultural Challenge: Silos Are Hard to Break

Shifting testing and security left requires more than tool adoption—it demands genuine cultural change. “Cultural imperatives are very hard for organizations to adopt because organizations reject culture change like viruses,” said Synopsys’ Steven.

Even organizations that nominally adopt DevOps often fall into a familiar trap: they hire a “DevOps engineer” who reports into operations, effectively creating a new role inside an existing silo rather than breaking silos down. “They’ve taken this cultural imperative to break down the walls, and they’ve turned it into a role in one of the silos, which is of course a perversion of the intent,” Steven explained.

The companies that have scaled successfully tend to be those that genuinely distributed security responsibility. In those organizations, the security team operates more like a coach—setting standards, providing visibility into what is working and what is not, and enabling other teams to act on that information—rather than functioning as a bottleneck gate.

Pete Chestna, Director of Developer Engagement at CA Veracode, added that organizational accountability structures matter enormously. If development teams are not held accountable for the security of what they build, they will naturally delegate that responsibility elsewhere. “Once that becomes a non-option then they start to make that change real,” he said.

Teaching Developers to Code Securely

Shifting the security burden toward developers only works if developers actually know how to write secure code—and that education often does not happen automatically. “It’s a muscle that development organizations don’t have,” said Chestna.

The solution is continuous feedback and targeted training rather than after-the-fact correction. “If you allow developers to continue to code incorrectly and then correct them later, you’re not really helping them be better,” Chestna explained. “DevOps is all about continuous improvement. So we need to take the knowledge of what they struggle with and feed that back to them in the form of training and then measure whether or not that training was effective.”

Chestna drew a useful historical parallel: twenty-five to thirty years ago, developers assumed that someone else would test their code after the fact. Over time, test-driven development and unit testing became standard practice—developers now write tests as they write code. Security, he argued, can follow the same trajectory.

“Similarly, if we start to put security into the vein, we’ll have the same effect where graduates walk into a company and know: code has to be secure, it has to function, and it has to perform well,” said Chestna. “Those are things where if they’re taught earlier on, it just becomes part of their nature.”

This points toward a longer-term need to change university curricula so that secure coding is treated as a foundational skill alongside functionality and performance—not an optional or advanced topic.

The Role of AI and Automation

Artificial intelligence is increasingly discussed as a lever for addressing both the skills gap and the scale challenges inherent in modern application security. Miteiko of CodeAI explained the core proposition: “AI is extremely good at recognizing patterns and making statistical predictions based on its pattern recognition. Noise is a recognizable pattern. Once it has been recognized it can be filtered out. The quality and security issues that we are dealing with in code today are the same coding errors we fixed years ago.”

This means AI systems can, in principle, be trained to identify known vulnerability patterns at scale, filter out false positives that slow developer workflows, and surface the issues most likely to represent genuine business risk—a problem that John Steven identified as a core struggle for many organizations: distinguishing between what general security guidance says to look for and what actually matters for a specific business’s risk profile.

“The future belongs to intelligent machines which are able to augment some of the security testing functions while working alongside humans,” Miteiko said. “A shortage of skilled security professionals on both sides—AppSec and CyberSec—and their relatively high cost will drive an adoption of intelligent automation powered by AI systems.”

Where the Industry Is Heading

Looking forward, the consensus among practitioners is that the trend toward embedded, automated, shift-left security will only accelerate. Cloud-native application architectures—containers, microservices, serverless functions—are designed to be portable and environment-agnostic, which makes language- or environment-specific security tooling of the past less relevant and creates an opening for more unified security approaches.

Osnat predicted that development platform vendors will increasingly embed security tooling directly into their platforms, rather than leaving it as an afterthought or an add-on. Software vendors themselves will be expected to ship secure tooling, not just functional tooling.

“If vendors are able to provide the industry with tools that have the capabilities required to win this security game, we’ll begin to see drastic improvements in the overall security posture,” said Miteiko.

Key Takeaways for DevOps Teams

  • Embed security tools in the CI/CD pipeline so that vulnerabilities are caught at build time, not after deployment.
  • Automate security testing at every stage—static analysis, dynamic testing against pre-production environments, and continuous monitoring in production.
  • Make security a shared responsibility between development and security teams, with clear policy ownership residing in security and implementation accountability sitting with developers.
  • Invest in developer security training and create feedback loops so developers understand the specific mistakes they are making and can correct them over time.
  • Treat cultural change as seriously as tooling—breaking down silos requires organizational accountability structures, not just new job titles or tool purchases.
  • Evaluate AI-assisted security tooling for pattern recognition, noise reduction, and risk prioritization to help smaller security teams operate at the scale of modern development velocity.
0 0 votes
Article Rating
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Oldest
Newest Most Voted
0
Would love your thoughts, please comment.x