How SCA, SAST, and DAST Protect Modern Apps (Application Security)

Summary

This episode explores the core tools in application security - SCA, SAST, and DAST and how they form a comprehensive, shift-left security strategy to protect modern applications from vulnerabilities throughout the development lifecycle.

Key Topics

Shift-left security strategy
SCA (Software Composition Analysis)
SAST (Static Application Security Testing)
DAST (Dynamic Application Security Testing)

Chapters

00:00 Introduction to Application Security
05:08 Understanding SCA: Software Composition Analysis
08:22 Exploring SASD: Static Application Security Testing
13:23 Diving into DAST: Dynamic Application Security Testing
17:37 Integrating Security Tools for Comprehensive Protection
21:31 Conclusion and Key Takeaways

Keywords

#Application Security, #SCA, #SAST, #DAST, #Shift-Left Security, #Cybersecurity, #SoftwareVulnerabilities, #OpenSourceSecurity, #DevSecOps, #SecurityTools

Let’s Stay Connected

📧 Email: santosh@getitrightsoln.co.uk

🔗 LinkedIn: linkedin.com/in/kssantosh

Transcript

SPEAKER_00 0:20

So, here's something nobody tells you when you start writing software. You're not just writing software, you're also adopting other software, including the ones that would have been written by so many other people in their process. Hundreds of little open source packages, each with their own histories, their own quirks, their own occasionally catastrophic security vulnerabilities. Something akin to what we covered in our previous episode, the light LLM supply chain breach in detail. Welcome to Secured by Design, the podcast where we explore how identity and wider cybersecurity shape the foundation of our digital world. I'm Santosh, and in each episode, I'll share insights and practical perspectives on how we can build security into every layer of technology and businesses. From identity, governance and zero trust to the latest in cloud and compliance. Let's dive into what it takes to design security that lasts. Today we are talking about three of the most essential types of tools in the modern application security toolkit SCA, SAST, and DAST. These are the core pillars of what we call a shift-left security strategy, meaning catch security issues earlier before they reach production, before they cost you everything. We'll break down what each one of us and how they actually work, and importantly, we'll ground all of it in real-world examples you've probably already heard about. Lock4 shell, the heart bleed bug, the case studies in what happens when these tools are missing or ignored. Alright, let's get into it. Before we talk about SCA, SAST, and DAST, we need to set the stage. What even is application security? What are we protecting and why? Let's start simple. An application, whether it's a mobile banking app, a SaaS platform, or an internal enterprise tool, is essentially a piece of software that interacts with users and data. And wherever there is interaction, there is potential for exploitation. Application security or AppSec is the practice of identifying, fixing and preventing security vulnerabilities in software applications. It's not just about firewalls and network parameters. Those are important too. But they are a different layer. AppSec is specifically about the code itself, the logic, the dependencies, the configuration, the runtime behavior. AppSec operates across the entire software development lifecycle or SDLC. From design and architecture all the way through coding, testing, deployment, and maintenance. The goal is to bake security in, not bolt it on at the end. Here's an analogy I love. Think about building a house. You could build the whole house, move in and then start checking if the locks are secure enough. Maybe add some bars on the windows, hire a security guard, or you could design the security into the house from day one. Better locks, reinforced doors, good lighting, a layout that doesn't create blind spots. That second approach, that's what AppSec tries to do with software. Remember, that is what we profess in this podcast, secure by design. Now, the threat landscape is enormous. We have the OWASP top 10, a list maintained by the Open Web Application Security Project, which outlines the most critical security risk to web applications. Things like injection attacks, broken access controls, security misconfigurations, and vulnerable and outdated components. That last one, that's precisely what SCA is designed to tackle. And we'll get there in just a moment. But here's the thing: as development has accelerated with teams adopting agile methodologies, as microservices and cloud native architectures have taken over, the attack surface has exploded. Modern apps don't just contain code written by your team, they contain dozens, sometimes hundreds, of open source libraries. They call external APIs, they are deployed through CACD pipelines that touch dozens of other systems. Each of those touch points is a potential entry point for an attacker. So the tooling also needs to evolve accordingly, and that brings us to SCA, SAST, and DAST. Three distinct approaches that together give you as much more complete picture of your application's security posture. Let's take them one at a time. SCA or software composition analysis. Let's talk about this one first, because it addresses one of the most underappreciated risks in modern development, your dependencies. Here's a reality check. When developers build applications today, they don't write everything from scratch. Why would they? There are incredible open source libraries out there: npm packages for JavaScript, pip packages for Python, Maven dependencies for Java, etc. The list goes on. A typical modern application might import hundreds of third-party packages. Those packages import their own packages, and so on. This is called the dependency tree, and it can be surprisingly very deep. You might have a direct dependency on React, and React has its own dependencies, and those may have dependencies. And somewhere four or five layers deep might be a tiny utility library with a known vulnerability that nobody on your team has ever heard of. SCA tools are designed to see into this tree. They scan your project's dependency manifest files, your package.json, your requirements.txt, your pom.xml, and they build a complete inventory of everything your application is using. Then they compare their inventory against databases of known vulnerabilities, primarily the CVE database, or the common vulnerabilities and exposures maintained by NIST. If a library in your stack has a known CVE, the SCA tool flags it, tells you the severity score using the CVSS scoring system, which goes from 0 to 10. Higher the worser. And also, IDD tells if there is a patched version available. Let me explain further with a real-time example. In December 2021, a vulnerability was discovered in Log4J2, a widely used Java logging library. It was rated 10 out of 10 on CVSS scale because Log4j was embedded in thousands of applications, from Apple iCloud to Amazon AWS to enterprise software from Cisco, IBM, and VMware. The impact was global. Companies scrambled to find out if they even had Log4J in their stack. Many didn't know. SCA tools that were already in place could answer that question in seconds. Those without the spent days doing manual inventory. This is textbook SCA territory. The tools in the space include SNCC, Sonotype, Black Trek, Wiz, and more. Most modern CICD pipelines can integrate these tools so that every pull request is automatically scanned for newly introduced vulnerable dependencies. But SEA doesn't stop at vulnerabilities. It also handles license compliance. Open source libraries come with licenses, a variety of them. MIT, Apache 2.0, GPL, LGPL, and some of those licenses have implications for commercial software. For example, if your product ships with GPL license code, for instance, you might be legally required to open source your entire product. SCA tools help legal and engineering teams track this. Key takeaway on SCA you can't secure what you can't see. SCA gives you visibility into the third-party code you're trusting your application to run on. In an era of supply chain attacks where attackers compromise upstream packages to get into downstream applications like what we saw in the recent light LLM attack, this is non-negotiable. Next, let's look at SAST or static application security testing. If SCA is about the libraries you use, SAST is about the code you write. The word static is key here. SAST analyzes your source code, bytecode or binaries without actually running the application. It's a bit like proofreading a script before the movie is filmed. You're looking for problems in the text itself. These representations let the tool trace how data moves through your application, from inputs like user-submitted form fields to processing logic to outputs like database queries or HTTP responses. The tool looks for dangerous patterns. A classic example, if user-supplied input flows directly into an SQL query string without proper sanitization or parameterization, that's a classic SQL injection vulnerability. SAST can catch this at the code level without ever running the app. What common kinds of vulnerabilities does SAST catch? Yeah, it can be SQL injection, cross-site scripting, path traversal, can be hard-coded credentials like an APA key or password sitting right in the source code. Can also look at insecure cryptography like using MD5 for password hashing, buffer overflows in lower level languages like C and C, to name a few. Some popular SAST tools are Checkmarks, Vera code, Sonacube, 45, and Code QL, which GitHub integrates directly. Many of these plug into your IDE so our developers get real-time feedback as they type, like a spell checker, but for security bugs. Let's look at another real-world example. This will emphasize the role of SAST. If you remember, we had something called the HeartBleed vulnerability. A blast from the past. HardBleed was a catastrophic vulnerability in OpenSSL, the most widely used cryptographic library in the world. It was a buffer over read vulnerability caused by a missing bounce check in the implementation of the TLS Heartbeat expansion. This extension allowed one computer to send a heartbeat request to another to keep the connection alive. Attackers could request large chunks of servo memory artificially, which with repeated use can cause exposure of private keys, passwords, session tokens from the server's memory. This kind of bounce checking errors reading beyond the allocated buffer is exactly what SAST tools analyze C and C code for. Had SAST been rigorously applied to the OpenSSL code base, there's a strong argument this bug could have been caught before it went into production in 2012. It wasn't discovered until 2014, two whole years in production on servers handling a significant portion of the internet's interpreted traffic. Let that sink in. Now, SAST isn't perfect, and I want to be honest about that. It has a reputation for false positives. The tool will flag issues that aren't actually exploitable in context. This can create alert fatigues in development teams if not managed carefully. Good SAST implementations involve tuning rules, prioritizing findings by severity, and integrating triage workflows. Also, SAST is language-specific. A tool built for Java isn't going to analyze Python. So in PolyCloud organizations where teams use multiple languages, you may need multiple SAST tools or a platform that supports many languages out of the box. Bottom line on SAST, it lets you find bugs in your own code before attackers do. It's your first line of defense at the source level. And when integrated into the CA CD pipelines, it makes security a normal, continuous part of the development process, not a gate at the end. Alright, you've talked about knowing your dependencies with SCA and analyzing your own code with SAST. Now let's talk about dynamic application security testing or DAST. Here's the key difference. DAST tests your application while it's running. It's a black box approach. The tool has no access to your source code. It interacts with the application exactly the way an attacker would. Sending HTTP requests, submitting forms, manipulating inputs, and observing what comes back. DAST is essentially automated ethical hacking. The tool acts like a malicious user, probing endpoints, fuzzing inputs, injecting payloads, and looking for responses that indicate a vulnerability. Did the server throw a detailed error message, revealing stack traces? Did a payload cause unexpected behavior? Did an input make it into an unescaped HTML response? Because DEST operates from the outside in, just like a real attacker. It catches vulnerabilities that only manifests at runtime. Configuration issues, authentication flaws, server misconfigurations, issues in third-party integrations, things that static analysis simply cannot see because the code isn't running. The most famous DAST tool is probably OWASP Zap, Z Attack Proxy. It's free, open source, and widely used. Then you have commercial tools like Burp Suite, Invict T, Rapid7 to name a few. What does DAST find? You can look at cross-site scripting that wasn't caught at code level because the payload actually needed to render in a browser to be confirmed. You can look at SQL injections by sending test payloads and seeing if the database responds differently. You can also look at broken authentication like session tokens that don't expire or login endpoints that don't lock out after repeated failures. Security mixed configurations like verbose error messages, open admin panels, directory listing enabled, etc. And it can also look at things like open redirect vulnerabilities, server-side request forgery, etc. Let's look at another real-world example. Between 21st August and 5th September 2018, British Airways suffered a breach that exposed the payment card details of around 500,000 customers. It was carried out by a notorious cybercriminal group known as MageCart. Investigators found that attackers had injected malicious JavaScript into the BA website, a technique known as web skimming. The script sat quietly on the payment page, harvesting card data as customers typed it in. A DAST tool scanning the live application, particularly looking for unexpected JavaScript on sensitive pages and testing for cross-site scripting injection vectors could have flagged anomalies. DAST tools can also detect when response include injected content that wasn't there in the previous scans. May I add on a side note that the attackers were able to add the malicious code to the JavaScript file using compromise credentials from a third party and moving laterally once inside the DA network. So there is always a identity element to it. Okay, let's keep that on the back of our mind and move back to the topic at hand. Now, there are some important limitations to DAST too. It's slower than SAST because it requires a running application. It needs realistic test environments. You don't want to be running aggressive scanning against your production database. It can also miss code paths that are hard to reach through the web interface. And like SAST, it too can generate false positives. The key takeaway on DAST is it tests your application in the real world. After all the static analysis, after all the dependency scanning, you need to know what the app actually does when someone starts poking at it. DAST answers that question. Okay, so you've got three tools. You're probably wondering, do I need all the three? Can I just pick one? Let me break this down practically. The honest answer is they are complementary, not interchangeable. Each covers a different surface area. Think of it like this. Use it from day one of development every time a new dependency is added, and continuously as new CVEs are disclosed against libraries you already use. It's fast, it runs early, and it protects you from vulnerabilities you don't write. SEST is your code quality and security companion. It runs during development, ideally in your IDE, in real time, and then has a CA gate on every pull request. It cannot see runtime behavior, but it's brilliant at catching bugs in first-party code before the code is even deployed. TASD is your pre-production security stress test. Run staging environments in QA and as part of your release gate before you ship it to production. It catches things that only appear at runtime, like misconfigurations, integration issues, authentication flaws that neither SCA nor SAST will ever see. No single tool is sufficient. Mature AppSec program uses all three as layers of defense in-depth strategy. The cost of running these tools in your pipeline is orders of magnitude less than the cost of a breach. Lock for shell, heart bleed, VA, every one of these could have been caught earlier with better tooling in place. If you are just starting out and you have to pick one, I would suggest start with SCA. It's the quickest win and gives you the best bang for the bug. Then layer in SAST, then DAST. Build the habit, build the process, and over time you build a genuinely robust app stack posture. Today we covered a lot of ground. Here are the big ideas I want you to walk away with. Number one, application security is about protecting the software you build. The code, the dependencies, the runtime behavior. It's not just firewalls and networks. It's the application itself. Number two, SCA or software composition analysis scans your open source dependencies for known vulnerabilities and license issues. Log4 shell is a reminder of what happens without it. Number three, SAST analyzes your source code without running it, looking for dangerous patterns like SQL injection, hardcoded credentials, and buffer overflows. Hard bleed is a lesson in what unreviewed C code can cost. Number four, DAST tests your running applications from the outside exactly the way an attacker would. British Airways Incident is a reminder that what works in code doesn't always work safely in production. Number five, I would suggest use all three together early and continuously. Shift left. Find bugs when they are cheap, not when they are catastrophic. Security isn't a checkbox you tick before release. It's a practice, a continuous discipline built into every step of how you write, review, and shift software. Thanks for listening to Secure by Design. If today's episode gave you something to think about, subscribe and follow on your favorite streaming platform for more discussions on identity and cybersecurity. Please do consider taking your time to rate this show. I would really appreciate that. That is one of the best ways for you to support this podcast and help grow this by providing feedback. Please feel free to share it with your team. You can also connect with me on LinkedIn for updates and new episode releases. Until next time. Stay secure, stay resilient, and stay secure by design.