Today, we’re thrilled to sit down with Malik Haidar, a seasoned cybersecurity expert who has spent years safeguarding multinational corporations from sophisticated threats and hackers. With a deep background in analytics, intelligence, and security, Malik brings a unique perspective on integrating business needs with robust cybersecurity strategies. In this interview, we dive into the evolving world of DevSecOps, exploring how concepts like ‘shifting left’ and ‘shifting right’ reshape software security, the hidden dangers of end-of-life software, and innovative ways to bridge security gaps. Let’s get started.
How would you describe the concept of ‘shifting left’ in DevSecOps, and why does it matter so much in today’s development landscape?
‘Shifting left’ is all about embedding security right from the get-go in the software development process. Instead of treating security as a final checkpoint before release, it’s integrated into the design, coding, and testing phases. This matters because catching vulnerabilities early—before they make it to production—saves time, money, and headaches. It’s far easier to fix a flaw in the planning stage than to patch a live system under attack. Plus, it fosters a culture where developers think about security as part of their daily work, not an afterthought.
What are some practical steps teams can take to implement ‘shifting left’ effectively in their workflows?
Teams can start by integrating static code analysis tools into their IDEs to flag issues as developers write code. Setting up automated security scans in CI/CD pipelines is another big win—it ensures every commit gets checked for vulnerabilities. Also, training developers on secure coding practices helps build that early awareness. Finally, involving security teams in sprint planning or design reviews ensures risks are spotted before they’re coded in. It’s about making security a seamless part of the process, not a bottleneck.
Can you break down what ‘shifting right’ means and how it complements the development process?
‘Shifting right’ focuses on security after the software is deployed in production. It’s about real-time monitoring, detecting anomalies, responding to incidents, and ensuring resilience in live environments. This complements development by addressing threats that couldn’t be caught earlier—think zero-day exploits or misconfigurations that only surface under real-world conditions. It’s the safety net that keeps systems secure even when something slips through the cracks during development.
What’s an example of a tool or approach that really supports ‘shifting right’ in a meaningful way?
A great example is using runtime application self-protection tools, or RASP, which monitor applications in production and can block exploits on the fly. Another approach is setting up robust logging and incident response systems to detect and react to unusual behavior quickly. These tools and practices act like a constant guard, watching for threats in the wild and giving teams the ability to respond before damage spreads.
How do ‘shifting left’ and ‘shifting right’ come together to create a stronger security posture across the entire software lifecycle?
When you combine ‘shifting left’ and ‘shifting right,’ you’re essentially covering both ends of the spectrum—prevention and reaction. ‘Shifting left’ reduces the number of vulnerabilities that make it to production by catching them early, while ‘shifting right’ ensures that anything missed is detected and mitigated in real time. Together, they create a continuous security loop, from code to deployment, minimizing risks at every stage and building resilience into the system as a whole.
One issue that often gets overlooked is end-of-life software. Why is EOL such a critical security concern for enterprises?
End-of-life software is a huge blind spot because once a component reaches EOL, the community or vendor stops releasing security patches. That means any new vulnerabilities discovered after that point go unaddressed, leaving systems wide open to attacks. Enterprises often rely on specific versions of open-source software for critical workloads, and attackers know this. They target EOL software precisely because it’s a sitting duck—no updates, no fixes, just waiting to be exploited.
Why can’t ‘shifting left’ or ‘shifting right’ fully solve the risks tied to EOL software?
‘Shifting left’ can flag that a component is nearing EOL or has known vulnerabilities, which is helpful for awareness, but it can’t produce patches for unsupported software. ‘Shifting right’ can detect when someone’s trying to exploit those gaps in production, but without a fix to apply, you’re just playing whack-a-mole with threats. Both approaches give visibility, but they don’t address the root issue: the lack of ongoing security support for EOL components.
What are some of the biggest hurdles enterprises face when trying to upgrade software to avoid EOL risks?
Upgrading software in an enterprise setting is often a nightmare. It’s not just about installing the latest version—there’s extensive testing to ensure compatibility with existing systems, retraining staff, and managing downtime. Plus, business priorities and budgets don’t always align with the rapid pace of open-source updates. Many organizations are stuck on older versions because the cost and risk of upgrading outweigh the perceived urgency, even when security is on the line.
How can extended security patching services help bridge the gap for EOL software challenges?
Extended security patching services step in where official support ends. They provide backported security fixes—meaning they take patches for newer versions and adapt them to work on older, unsupported ones. This buys enterprises time to plan upgrades without leaving systems exposed. It’s a lifeline that keeps critical software protected, ensures compliance, and prevents the need for rushed, risky updates just to close a security hole.
Looking ahead, what’s your forecast for how DevSecOps will evolve to address challenges like EOL software and beyond?
I think DevSecOps will continue to mature by integrating more proactive strategies for lifecycle management, not just during development or production but well past official support windows. We’ll likely see tighter integration of automated tools that predict and manage EOL risks before they become crises. Additionally, I expect broader adoption of extended support services as organizations realize that security can’t stop at EOL. The future is about true end-to-end protection, where no stage of a software’s life is left unsecured.
