124 episodes

Curious about application security? Want to learn how to detect security vulnerabilities and protect your application. We discuss different topics and provide valuable insights into the world of application security.

DevelopSec: Developing Security Awareness Jardine Software Inc.

    • Technology
    • 4.0 • 3 Ratings

Curious about application security? Want to learn how to detect security vulnerabilities and protect your application. We discuss different topics and provide valuable insights into the world of application security.

    Ep. 120: Addressing Root Cause - Vulnerable Components

    Ep. 120: Addressing Root Cause - Vulnerable Components

    In this episode we talk about addressing the root cause of an issue versus the symptoms. How can the process of keeping application components updated be improved?
     
    For more info go to https://www.developsec.com or follow us on twitter (@developsec).
     
    DevelopSec provides application security consulting and training to add value to your application security program. Contact us today to see how we can help.
     
    Transcript:
    In this episode, James talks about root cause analysis versus treating the symptoms.
     
    Tackling the challenge to integrate security into the development process, looking for insights, answers and practical solutions to avoid getting overwhelmed. Welcome to the develop SEC podcast where our focus is your success in securing and improving development processes. And here's your host, James Jardine. Hey, everyone, welcome back to the show. Today, I want to talk about addressing the symptoms versus addressing the root problem. And I think in application security, or when we talk about secure development, this is something where a lot of times we address the symptoms, but we never really take the step back to address the actual root cause of what's causing those symptoms. And today, I want to actually talk about vulnerable third party components. This is something that has been kind of brought to the attention a lot more in the past few years, made it into the OWASP, top 10. And it's something I think everybody struggles with, we never know when we'll have a vulnerable third party component, because until somebody actually identifies a vulnerability, we just assume that we're good. And then on top of that, if there is a vulnerability identified, then we also run the chances that we're probably not even using that feature.
     
    So vulnerable third party components are a really interesting aspect, when we think about secure development. Because there is a lot of unknowns, we may know that there's a vulnerability there. But the actual knowledge of do we use that piece and are we vulnerable, can be difficult, which, in the end, ends up adding a whole bunch of extra work and a whole lot of time for us to try to figure this out and address this stuff. And so this is where I talk about addressing the symptoms. In this case, in a lot of places, what we do is we address that symptom, we know that there's an issue of vulnerable third party components, right, that's the symptom, we have a vulnerable third party component. And so most places have some sort of process in place where we're going to identify these right, we're going to scan them all the time, whether using some of the common commercial tools, maybe you're using a free open source tool. But basically, the way it goes is I'm going to scan my repos or I'm going to scan my packages, and I'm going to look for all the dependencies, and then I'll look at their dependencies, and we'll see if there's any known vulnerable components within these right. And that requires having some sort of CVE out there that says, hey, somebody has found this, they've reported it, I remember requiring this to be a reported vulnerability. But we know that there's a vulnerability in this component.
     
    And so now every time I scan my package, it goes and looks up to say, hey, there any known vulnerabilities for this package, and then we send it back. And then of course, the difficulty of trying to rate this and understand, you know, is it a low? Is it high? Is it critical? Love these systems, right, from a generic standpoint might say that it's critical vulnerability, but is it really of critical vulnerability? And a lot of cases, probably not, we've had a few that definitely were. But not everything is critical. Even if the CVE listed out, as you know, high or critical, it depends on your environment and how you're using that system. So there's a lot of extra work that goes around that, of course, to try to avoid that, you know, if we could just patch everything

    • 16 min
    Ep. 119: Risks of SpellCheck

    Ep. 119: Risks of SpellCheck

    In this episode we talk about the spell check feature of the browser and how it could present a risk to sensitive data.
     
    Link to article referenced: https://www.darkreading.com/application-security/spellchecking-google-chrome-microsoft-edge-browsers-leaks-passwords
     
     
    For more info go to https://www.developsec.com or follow us on twitter (@developsec).
     
    DevelopSec provides application security consulting and training to add value to your application security program. Contact us today to see how we can help.

    • 12 min
    Log4J Sparking Thought on Vulnerable Components

    Log4J Sparking Thought on Vulnerable Components

    Log4J has been the talk of the town recently and everyone is focused on the technical details of the specific vulnerabilities found. In this episode, James talks about the overarching ideas around dealing with vulnerable components. Are you vulnerable? If so, what needs to be done?
    For more info go to https://www.developsec.com or follow us on twitter (@developsec).
    Join the conversations.. join our slack channel. Email james@developsec.com for an invitation.
     DevelopSec provides application security training to add value to your application security program. Contact us today to see how we can help.

    • 24 min
    How Browsers are Helping with Security

    How Browsers are Helping with Security

    Chrome has announced a few changes that we need to watch out for in the near future. We previously talked about the default value for samesite that is coming up fast. I wrote about this here: https://www.jardinesoftware.net/2019/10/28/samesite-by-default-in-2020/
    Also, they are getting ready to start blocking mixed content downloads:
    https://blog.chromium.org/2020/02/protecting-users-from-insecure.html
     
    For more info go to https://www.developsec.com or follow us on twitter (@developsec).
    Join the conversations.. join our slack channel. Email james@developsec.com for an invitation.
     DevelopSec provides application security training to add value to your application security program. Contact us today to see how we can help.

    • 13 min
    Chrome Retires XSS Auditor

    Chrome Retires XSS Auditor

    It was recently announced that Chrome was dropping the XSS Auditor in Chrome 78. What does that mean and how does that change things for you as a developer?  
    https://www.chromium.org/developers/design-documents/xss-auditor
    For more info go to https://www.developsec.com or follow us on twitter (@developsec).
    Join the conversations.. join our slack channel. Email james@developsec.com for an invitation.
     DevelopSec provides application security training to add value to your application security program. Contact us today to see how we can help.

    • 14 min
    Is CSRF Really Dead?

    Is CSRF Really Dead?

    In 2020, Chrome will default the SameSite attribute to Lax on all cookies. SameSite helps mitigate CSRF, but does that mean CSRF is Dead?
    For more info go to https://www.developsec.com or follow us on twitter (@developsec).
    Join the conversations.. join our slack channel. Email james@developsec.com for an invitation.
     DevelopSec provides application security training to add value to your application security program. Contact us today to see how we can help.

    • 15 min

Customer Reviews

4.0 out of 5
3 Ratings

3 Ratings

Top Podcasts In Technology

Lex Fridman Podcast
Lex Fridman
All-In with Chamath, Jason, Sacks & Friedberg
All-In Podcast, LLC
Acquired
Ben Gilbert and David Rosenthal
TED Radio Hour
NPR
Dwarkesh Podcast
Dwarkesh Patel
Hard Fork
The New York Times