Introduction:

In the modern world, the most critical vulnerability often isn’t a misconfigured firewall or an unpatched OS—it’s the code itself.

From understanding the OWASP API Top 10 to navigating the complexities of DevSecOps and tackling unique challenges like the “Mother’s Secret” and “Traverse” rooms, this section transformed how I view the software supply chain. Here’s what I learned.

1. OWASP API Security Top 10

For years, the OWASP Top 10 for Web Applications dominated the conversation. But as applications evolve into microservices and APIs, the attack surface has shifted.

Key Insights:

  • APIs are the New Perimeter: Modern apps rely heavily on APIs. If an API is broken, the entire backend is exposed.
  • Broken Object Level Authorization (BOLA): It’s not just about logging in; it’s about ensuring User A can’t access User B’s data just by changing an ID in the URL.
  • Mass Assignment & Injection: How developers accidentally expose internal properties or allow SQL/NoSQL injection through poorly validated API inputs.
  • Lack of Resources & Rate Limiting: APIs without rate limiting are easy targets for brute-force and DoS attacks.

2. SSDLC and DevSecOps

The Secure Software Development Life Cycle (SSDLC) isn’t just a buzzword; it’s a methodology that changes when security happens. SSDLC

The Shift Left Philosophy:

  • Requirements Phase: Security requirements are defined alongside functional ones.
  • Design Phase: Threat modeling happens before a single line of code is written.
  • Development Phase: Developers use secure coding guidelines and static analysis tools.
  • Testing Phase: Dynamic analysis and penetration testing occur before release.
  • Deployment & Maintenance: Continuous monitoring and patching.

Enter DevSecOps:

DevSecOps is a cultural shift that makes SSDLC possible. It’s about automating security checks within the CI/CD pipeline so that security doesn’t slow down delivery—it enables it.

  • Automation is Key: If security checks are manual, they will be skipped. If they are automated, they become part of the build process.
  • Feedback Loops: Developers get immediate feedback on vulnerabilities, allowing them to fix issues instantly rather than weeks later.

3. SAST, DAST, and Weaponization

How do we actually find these bugs? There are two primary types of application security testing.

SAST (Static Application Security Testing):

SAST

  • What it is: Analyzing source code without executing it.
  • Pros: Finds issues early (during coding), covers 100% of code paths.
  • Cons: Can produce false positives; doesn’t catch runtime issues.

DAST (Dynamic Application Security Testing):

DAST

  • What it is: Testing the running application from the outside (like a black-box attacker).
  • Pros: Finds runtime issues, configuration errors, and authentication flaws.
  • Cons: Can’t see inside the code; only tests what’s exposed.

Weaponizing Vulnerabilities:

To defend effectively, I had to understand how attackers weaponize vulnerabilities.

  • Exploitation Chains: How a small XSS flaw can lead to session hijacking.
  • Payload Delivery: Understanding how malware or ransomware is delivered through vulnerable software.
  • Impact Analysis: Seeing the real-world consequences of a successful exploit helped me prioritize which vulnerabilities to fix first.

Conclusion:

After reading about software security topics it has fundamentally changed my perspective on the software lifecycle. I now understand that:

  1. APIs are critical: They require specific security controls distinct from traditional web apps.
  2. Shift Left is mandatory: Waiting until the end to test for security is too late and too expensive.
  3. Automation is essential: SAST and DAST must be integrated into the CI/CD pipeline.
  4. Human insight matters: Tools find bugs, but humans find logic flaws and understand the business impact.

A Security Engineer role is to bridge the gap between developers and security. It needs to speak their language, provide them with the right tools, and help them build software that is secure by default.

This section was a reminder that the code we write is the foundation of our digital world. If that foundation is cracked, everything built on top of it will eventually fall.