Software Engineering Articles

I’ve been thinking about security and how frequent security lapses put all of us on edge. My personal information has appeared multiple times on Have I Been Pawned, and it’s incredibly frustrating especially knowing that many of these breaches happen at billion-dollar companies running multi million-dollar projects with teams of highly skilled professionals working around the clock. Despite having significant resources and expertise, these organizations still experience major data breaches that expose our personal information. Why does this keep happening ?

Generally, companies don’t rely on a single control or tool for security. Instead, they use a “defense-in-depth model, meaning multiple layers of protection are applied across people, processes, infrastructure, networks, and applications. The goal is that if one layer fails, others still reduce or contain the risk.

Most mature Companies manage security through a combination of

• Policies & Governance – security standards, risk management, compliance (ISO 27001, SOC2, HIPAA, PCI-DSS, etc.).
• Secure SDLC / DevSecOps – security embedded into every stage of development (design  coding  testing  deployment  operations).
• Security Teams and Roles
• AppSec engineers
• Security architects
• SOC / monitoring teams
• Red teams / penetration testers
• Automation & Tooling – scanning, monitoring, logging, incident response systems.
• Training and Awareness  for developers with secure-coding training, phishing simulations, insider-threat prevention etc.

We often say security is treated as a continuous lifecycle or moving goal, not a one-time control or activity.

There are often more than 5 to 10 layers of defense which companies implement in order to ensure that security is not compromised and they are often implemented at

– Physical and Infrastructure Security

• Data center security, access controls, CCTV, badges
• Cloud provider infrastructure controls

– Network Security

• Firewalls, VPNs, security groups.
• Network segmentation / zero-trust networks
• Intrusion detection & prevention (IDS/IPS)

– Host / Endpoint Security

• OS hardening
• EDR / anti-malware
• Patch and vulnerability management

– Application Layer Security

• Secure coding practices (OWASP Top 10)
• Static and dynamic code scanning (SAST / DAST)
• Dependency / supply-chain scanning (SCA)
• Penetration testing & bug bounty programs

– Identity & Access Control

• Authentication and MFA
• Least-privilege access Role-based access control (RBAC)
• Secrets and key management

– Data Security

• Encryption at rest and in transit
• Data classification and masking
• Backup and recovery

– API and Service Security

• API gateways and rate limiting
• mTLS, OAuth, JWT validation
• Abuse and bot protection

– Monitoring and Detection

• SIEM / log monitoring
• Threat intelligence feeds
• Behavior analytics & anomaly detection

– Incident Response and Recovery

• Playbooks and response plans
• Forensics and containment
• Post-incident learning and improvements

– People and Process Controls

• Security training & awareness
• Insider-threat prevention
• Change management and audits

In addition to these companies also try to or at least try to mix and adopt DevSecOps and Open Worldwide Application Security Project (OWASP) principles in the development life cycles.

So even having these many layers of defense’s we still see the security issues. Why is that so ??

Over time, both agile and traditional software development processes have tended to emphasize features, speed, and delivery timelines over security. In many organizations even those investing millions of dollars and employing large teams security still ends up as a low-priority task addressed late in the project, or in some cases, not addressed at all. Teams often assume that multiple external layers of defense will protect them, reinforcing a mindset rooted in earlier engineering practices where functionality and business value were treated as the primary objectives, while security was viewed as an operational or infrastructure concern to be handled later.

Product owners and business leaders almost always prioritize customer-visible features and time-to-market because those outcomes directly drive revenue, competitive advantage, and executive performance metrics. Security, on the other hand, is usually viewed as expense rather than a value , especially when the benefits are invisible unless something goes wrong. This creates a trade-off environment where teams feel pressure to ship features quickly, sometimes bypassing security reviews, technical debt cleanup, or risk assessments in order to hit deadlines or launch windows.

Nearly all modern software is built from many interconnected components, with applications relying heavily on third-party libraries and frameworks to accelerate development and add functionality. However, these dependencies often introduce security vulnerabilities that can cascade into serious risks for the overall system, even if the application code itself is secure. In many organizations, remediation of these vulnerabilities is delayed or deprioritized because teams are under constant timeline pressure, fear that upgrades may introduce regressions, or classify the fixes as “technical debt” to be addressed later. As a result, known security issues can remain unresolved in production for long periods of time, increasing exposure and making dependency management and timely patching a critical yet frequently neglected part of application security.

Now that we understand, at a high level, how organizations implement security, it’s clear that security cannot exist as a siloed phase in the lifecycle. Instead, it needs to be integrated seamlessly into the SDLC, functioning as a continuous and measurable quality attribute throughout the development process. In this context, DevSecOps provides a strong foundation, as it embeds security practices directly into development and operations rather than treating them as an afterthought. Some of the ways we can integrate security into SDLC is via

Integrating Security into SDLC Process

SDLC Phase	Security Activity (OWASP Alignment)	Outcome/Artifact
Requirements	Define security requirements and non-functional requirements (e.g., must support MFA, must protect PII).	Security Requirements Document
Design	Threat Modeling (focused on Insecure Design). Review architecture against OWASP principles (e.g., Least Privilege).	Threat Model Report/Data Flow Diagram
Development	Use secure coding practices, integrated SAST/SCA in IDE, use OWASP Cheat Sheets.	Secure Code & Clean SAST/SCA Scan
Testing/QA	Dynamic Application Security Testing (DAST) and Penetration Testing (check for OWASP Top 10 risks).	Security Test Report/Pentest Findings
Deployment	Secure Configuration Management (Security Misconfiguration) and continuous security monitoring.	Hardened Environment/Configuration Baseline

Embedding in Agile/Scrum Planning

• Security Stories in Backlog: Create security user stories or Security Epics that address specific risks or OWASP risks (e.g., “As a user, I should not be able to bypass access controls to view another user’s account details.”). This ensures security work is prioritized and tracked.
• Sprint Planning:- Dedicate a portion of every sprint to security, often as a spike for threat modeling a new feature or as a task to remediate high-priority security defects from automated scans.
• Definition of Done (DoD):- Security must be part of the DoD. Feature is not complete until it passes the security checks, which should include “Feature has been threat modeled,” and “Secure code review completed.”
• Retrospectives:- Review security incidents or near-misses during the sprint retrospective to identify root causes and improve the secure development process continuously.
• Every sprint should proactively review whether any dependencies contain security-related vulnerabilities and plan remediation work as part of the sprint, rather than deferring everything into a single large ticket later. Integrating dependency risk assessment into the regular sprint cycle ensures that vulnerabilities are addressed incrementally and consistently, instead of accumulating as unmanaged technical debt.

So, the next time we run into a security issue, instead of simply logging it as another task, what if we pause and ask our product and technology leaders a deeper and meaningful question

Is this just a backlog item or that our approach to security needs to change ?

With hope that this question might spark a much more meaningful conversation about risk, priorities, and how seriously we treat security in the lifecycle.

I believe the very definition of security will evolve in the era of AI, and the way we approach it will fundamentally change. As AI becomes more advanced and fully mainstream, a significant portion of our work will shift toward identifying, managing, and mitigating AI-driven threats. We’ll increasingly face challenges such as deepfakes, AI-generated voice agents, and synthetic videos that convincingly mimic real users and legitimate interactions. In this future, security won’t just be about protecting systems or data it will also be about protecting identity, authenticity, and trust in a world where what we see and hear can no longer be taken at face value.