Building Secure Software An Introduction to SSDLC, SAST, DAST, SCA & Secret Scanning

[Audio] Hello everyone — thanks for joining. Today I want to talk about something that affects all of us as engineers: building secure software. I've had the opportunity to work with many of you, either directly or indirectly, on VAPT-related activities. Since I'm recording this session using an AI presenter, I've added a small photo of myself here, just so you know who's behind the session. So, with that, let's get started. We'll cover what S S D L C means, four key security practices —sast, dast, S C A, and Secret Scanning — and where we are as an organisation on this journey. This is purely an awareness session. There are no action items today. I just want to share some important context and help everyone understand why these practices matter. Let's begin..

[Audio] So, let's start with the basics. S D L C — Software Development Lifecycle — is the process we all follow to build software: plan, design, build, test, and deploy. Traditionally, security can sometimes be treated as something added towards the end — run a pentest before go-live, fix what you can, and then ship. The problem is that finding a vulnerability late in the cycle can be expensive, time-consuming, and sometimes means we're shipping with known risks. Secure S D L C, or S S D L C, flips that around. The idea is simple: build security into every stage of development, rather than treating it as an activity at the end. This concept is often called Shift Left — moving security earlier in the development process, where issues are generally cheaper and faster to fix. Think of it this way: fixing a bug during development is relatively simple. Fixing the same issue after it reaches production could cost days of effort, affect customers, impact trust, or worse..

[Audio] So, what are the four practices we're going to talk about today? SAST — Static Application Security Testing. DAST — Dynamic Application Security Testing. S C A — Software Composition Analysis. And Secret scanning. Each one catches different types of security issues at different points in the development process. Think of them as layers. Together, they provide much better coverage than relying on any single approach alone. Let's go through each one..

[Audio] First up — SAST, or Static Application Security Testing. The easiest way to think about SAST is to imagine a spell checker for your code. But instead of catching typos, it looks for potential security issues. SAST scans source code without actually running the application. That means it can potentially run in your IDE while you're writing code, or as part of a CI pipeline when you raise a pull request. What kind of things can it identify? Things like potential SQL injection vulnerabilities, cross-site scripting issues, insecure functions, and other security weaknesses in the code. The big benefit is that it catches these issues early — before the code is deployed or reaches production. Some popular SAST tools you might have heard of include SonarQube, Semgrep, and Checkmarx. When teams track SAST, they typically look at findings by severity — critical, high, medium, and low — as well as how quickly those findings are being addressed..

[Audio] Next — DAST, or Dynamic Application Security Testing. If SAST is like proofreading your code before it runs, DAST is like stress-testing the application while it's actually running. DAST simulates attacks against an application in a live or staging environment. It interacts with login pages, APIs, session handling, and other parts of the application — similar to the way an attacker might interact with them. And here's the important part: DAST can identify issues that SAST simply cannot. For example, authentication flaws, session management issues, and certain server or application misconfigurations may only become visible when the application is running and responding to requests. SAST and DAST are therefore complementary. You need both to get broader coverage. Some tools in this space include OWASP ZAP and Burp Suite. Typical metrics include vulnerability counts by severity and the percentage or scope of the application surface that has been tested..

[Audio] Now, S C A — Software Composition Analysis. Here's a reality check: a large portion of a modern application often consists of code that the development team didn't write themselves. We use open-source libraries, frameworks, and packages — npm packages, Maven dependencies, Python libraries, and many others. S C A helps identify vulnerabilities in these third-party components by checking them against databases of known vulnerabilities, commonly referenced through CVEs. Remember Log4Shell? That was a critical vulnerability in Log4j, a widely used logging library. Organisations had to quickly determine whether they were using affected versions and where those versions existed in their environments. S C A is one of the tools that can help with that visibility. It can also identify outdated dependencies and, depending on the tooling, potential open-source licence risks, which can be important for compliance as well. Tools like Snyk, Dependabot, and O W A S P Dependency-Check are commonly used in this area..

[Audio] This one surprises a lot of people. Secret Scanning looks for hardcoded secrets in code — things like API keys, database passwords, authentication tokens, and cloud credentials — that may have accidentally been committed to a repository. It happens more often than you might think. A developer may be testing something locally, hardcode a key to get it working quickly, and accidentally commit it. The problem is that Git history can retain that secret. Even if the file is deleted later, the secret may still exist in the repository history. And once a credential has been exposed, it should be treated as potentially compromised. Secret Scanning tools such as GitGuardian and TruffleHog can scan repositories, including their history, to help identify these exposures. The key metric here is simple: how many secrets are detected, and how quickly are they revoked or remediated?.

[Audio] So, where are we as an organisation right now? Security testing isn't new here. We already have a solid foundation, and we're building on it. We're doing Web VAPT — vulnerability assessment and penetration testing — on our web applications. We're also doing API VAPT specifically for our APIs, and we run both automated and manual penetration testing across these We track this through JIRA and our Power BI dashboard, which gives us visibility into SLA compliance, defect resolution status, vulnerability categories mapped to OWASP, and trends across projects and years. On top of that, we've built an S S D L C questionnaire, mapped to industry frameworks including NIST SSDF and OWASP SAMM, and we're currently piloting it on one application. So, the foundation is already there, it's working, and we're continuing to build on it..

[Audio] If you want to go deeper into any of these topics, there are some great free resources available. The OWASP Top 10 is one of the most widely referenced lists of critical web application security risks and is definitely worth bookmarking. NIST SSDF is the framework our S S D L C questionnaire is mapped to. OWASP SAMM is the maturity model we use to assess where we are. And the OWASP Testing Guide provides a detailed, hands-on reference for security testing practices. Now, let's quickly address a few questions that commonly come up. What's the difference between S S D L C and S D L C? S S D L C brings security into every stage of the development lifecycle, rather than treating it as an afterthought. SAST versus DAST? SAST analyzes code without running the application, while DAST tests the application while it's running. They complement each other. What is S C A? It's the process of analyzing third-party and open-source dependencies for known vulnerabilities and other risks. And does Secret Scanning look at personal files? No. It is focused on code repositories and identifying accidentally committed credentials or other sensitive secrets..

[Audio] So, to wrap up, the key message today is this: Security isn't just a security team problem. It's an engineering responsibility, and it belongs to all of us. S S D L C is simply a structured way to make sure we're thinking about security at every stage of development, rather than scrambling to fix things after the fact. SAST, DAST, S C A, and Secret Scanning are the practices that help make that approach real. Each one catches different types of issues at different points in the development lifecycle. We already have a strong foundation here — Web and API VAPT, automated and manual penetration testing, a Power BI dashboard tracking our findings, and an S S D L C questionnaire that we're actively piloting. And there's more we're exploring as things mature — ideas such as a Security Champions programme, expanding S S D L C to more projects, and developing a software engineering security policy. More on all of that as things take shape. For now, nothing changes for you today. This was purely an awareness session. But if you have questions, curiosity, or something you'd like to flag, please reach out to the security team. Thank you all for your time — and most importantly, for caring about the security of what we build and ship..