Shift Left without Losing Your Mind - Practical DevSecOps for Busy Teams - Callian Berends

[Music] Hi. So, thanks everyone for joining today. So, I'm Callian and in this lightning talk, I want to help you see that integrating security into your software development process doesn't have to be overwhelming. So, the title of this talk is shift left without losing your mind. Practical DevSec Ops for busy teams. Let's get started. Let's be honest, teams are busy. From sprint planning, daily standups, development, code review, QA testing, and bug fixes. Security often takes a backseat. Asking teams to do security can sound like an additional burden, but it doesn't have to be. There are ways to work with the current flow rather than against it. That's where DevSec Ops comes in. So, DevSec Ops is all about integrating

security into every phase of the software development life cycle from planning, coding, building, and testing all the way through to deployment and monitoring. You don't have to do everything at once. Start with lightweight steps that give you the most impact with the least disability. Let's start in the planning phase. A great first step is doing lightweight tread modeling. Just ask what could go wrong. That's it. No fancy tools required. Just start with a simple user story or feature and ask what could go wrong and have a look at the potential threats. Let's have a look at what thread modeling is. So trade modeling is analyzing representations of a system to highlight concerns about security and

privacy characteristics. The goal isn't perfection. its awareness. So it's best to be proactive rather than reactive. So there are a couple of trade modeling frameworks such as stride, pasta, dread and lynen. So a good starting point is stride which is basically the framework developed by Microsoft. It allows the teams to think of potential threats which is basically categorized in six types which is u spoofing, tempering, repudiation, information disclosure, denial of service and elevation of privileges. So basically let's have a look at a simple user story. So as a user I want to upload my picture so that it displays on my account. So now using the stride framework let's think about potential threats. So could an attacker upload a file

pretending to be another user? That's spoofing. Could an attacker modify the file, add malicious payloads, or alter the file type? That's tempering. Could an attacker upload an extremely large file which could lead to denial of service? So for each threat, think of the simplest mitigation. So in order to mitigate spoofing, validate the orthids before the file is being uploaded. To mitigate tempering, validate the image m as well as the file type. And to prevent denial of service, enforce size limits before uploading the file. So another great resource is OASP ASVS, the application security verification standard. So this reference can actually be used within teams to identify which controls fits best within the team and for the application.

So it's good to be used as a reference. So version five of the OAS ASVS was released the end of May. So the key is to start small. Focus on one feature at a time. Build awareness within your team and security will automatically become a habit. So let's move on to the development phase. Developers often repeat certain tasks. So it's important to create a reusable library which contain secure coding practices so that the developers can reuse this. So a couple of examples is authentication authorization input validation, output encoding in session management just to name a few. So what developers can also do is they can make use of IDE plugins to provide secure feedback in real time as they are

basically developing code. So there are tools such as sneak and sonar learn that basically provides them feedback feedback and help identify issues as they write code. Let's have a look at the build phase and what the team can do. So in the build phase, so you can basically add a security stage into your CI/CD pipeline to detect critical issues such as hard-coded secrets, making use of secret scanning tools and also making use of dependency SC scanning tools also known as software composition analysis tools. So what this will basically do is it will identify vulnerability in third-party dependencies or libraries. So while doing these type of scans in your pipeline, it's important not to break the build immediately. Start with

visibility. Let the teams see the findings and then you can slowly tighten or add enforcements. So there are code repositories such as GitLab and GitHub that already have these scanning features that I just mentioned. They already built in to some of the code repositories which can basically just be ena enabled for scanning within your CI/CD pipeline. Let's move on to the testing phase. So in the testing phase teams can introduce lightweight dynamic scanning also known as dash scans. So what it does is it basically analyzes your application a running application to identify vulnerabilities. Um, so there are tools like Zap which offers baseline scans which is brilliant to run on a daily basis because it's fast and

passive which means that it doesn't perform attacks against your application. What can also be done is teams can use this as a nightly schedule and basically evaluate the findings the following day as they step in the morning they can have a look at the findings that basically the um the scan provided they can go through the report having a look at the release stage. So in the release stage a a what teams can do is make use of a simple checklist. So the checklist can either be added in your pull request template or in your release ticket where you can just ask a couple of questions such as did we check that the orth as well as

the session tokens were validated? No, that the image file as well as the mime type we did validation on those types and that we have no system information that were exposed as well as the error messages that we have. It's user friendly so that it doesn't expose any system information and also that there's no hardcoded secrets within our source code. So onto the operating and monitoring phase. So there's a couple of checks that can be done in this phase as well. So some of them once your application have been deployed make sure that uh you enable centralized login set up monitoring and alerting implement health checks. Monitor for security events such as when your permissions change or when

the roles change. And another check you can do is apply security patching. So just as a summary what we can do is let's quickly just have a look at what we covered today. So in the planning phase do lightweight thread modeling. In the coding phase implement reusable secure coding templates. In the build phase, add a secure dependence secure secret scanning as well as dependency scanning to your pipeline. In the testing phase, do introduce dynamic scanning. In the release, add a security checklist. And in the operating morning moni monitoring, set up logging alerts and supply apply security patches. So just a reminder that just the right check in the right phase can make a change. So thanks thank you once again

for joining me today and I'm Kelly and Barren. Thank you.