250: Pushing Security Testing Left, Like a Boss with Tanya Janca

Founder: We Hack Purple (Academy, Community, and Podcast), WoSEC International (Women of Security), OWASP DevSlop, OWASP Victoria, #CyberMentoringMonday

• I feel that security is sort of like taking care of and protecting people. If that makes any sense. And I was really interested in it and I really wanted to do hacking. But one of the first jobs I got in security was actually doing Internet response and just being able to let everyone know everything's OK. Being able to figure out what happened and then block it from happening again stopping things partway through I just I felt so much pride to me it's this wonderful impact.
• For social engineering the main thing is is that you need to create policies and then make sure people actually follow the policies. So for instance, don't put them in a situation where they're likely to break the policy. For example, if you have a door where everyone has to badge in it's common for people to just walk behind someone else. And it's almost rude if they don't hold the door. So I've worked places where they have this turnstile. So it's just impossible.
• Another thing which I think is like the easiest bang for your buck is to do third-party component scanning. So when we write an app like 60 70 80 even 90 percent of it is actually libraries and then those things have vulnerabilities in them.
• I have this crazy idea that we should put critical types of scans in the CI/CD pipeline that go out to publish but then you can make another like a loop sort of like a circle and you hit every hardcode security check that's ever happened and then it just goes back to Dev and stops.
• Security tests have a lot of false positives and they have false negatives. For third party component, they're pretty good because it's kind of true or false. For example, you are using JQuery1.1 1.3 or you're not right. Or there is a CVE a common vulnerability a numerator like a record for a vulnerability that is in that or there isn't. So those there are few false positives with those, but with static code analysis, it's insane. It's like 95 percent false positives. And I know what you're thinking you're like That's awful. Why would anyone use it? Here's why. If you do a code review of 20,000 lines you have to read 20,000 lines of code. Now if you run a static analysis on it it might say hey I think I found 200 things and then you read those 200 things. It takes a lot less time than reading 20000 things and then you find others only 10 things. Thanks!
• If you want to learn about penetration testing you. I feel like it would be a good idea to decide if you are more interested in software or if you're more interested in infrastructure because there's kind of separate skills that you need for those.
• For actionable advice, you should read my blog. I'm writing up all of the things that I've learned in the past four almost five years of working in security, trying really hard to attract everyone else into security and I am writing how to add security to your pipeline. How to add security to your system development lifecycle. What is a secure coding guideline and like what should be in it and then I'm publishing one really soon as soon as I finish editing it and I feel like I've tried to make it really really helpful for beginners and at a level where you can ramp up really quickly.