Infosec advocate speaks to The Daily Swig about the benefits of, and barriers to, ‘shifting left’
“Software can’t be the best without being secure.”
This is according to Tanya Janca, who warns that businesses will “find themselves behind the security curve, so to speak”, if they don’t start to take DevSecOps seriously.
Janca’s own career has seen her transition from a software developer to an advocate for the adoption of DevSecOps across the IT industry.
In an interview with The Daily Swig, she spoke about why companies should adopt a ‘shifting left’ mindset, the barriers some security teams face in doing so, and why education is paramount to overcoming hurdles in the software development workspace.
Daily Swig: Much of your career has been dedicated to promoting the adoption of DevSecOps in the industry. Why are you so passionate about it, and why should companies learn to embrace it?
Tanya Janca: When I was a developer, I wanted to create the best possible software. However, when I switched to security, I realized that my software couldn’t be ‘the best’ if it wasn’t secure. Once I realized just how much of the industry had been in the dark about AppSec, I made it my mission to share the lessons I had learned.
I learned more and more over time and eventually realized that DevSecOps was the fastest way to deliver secure software, making it my favorite lesson. I believe companies will have to embrace DevSecOps, sooner or later; if they don’t, their vulnerabilities will harm their businesses, and they will find themselves behind the security curve, so to speak.
DS: What are the major challenges companies face when switching to a DevSecOps mindset? And how can they overcome these?
TJ: If a company is not already doing DevOps, switching to DevSecOps will be quite difficult. They will need to transform operations, development, and the security program at the same time. That’s a big learning curve and challenging for the security team to do alone. Getting buy-in from other teams would be essential.
That said, if a company has already embraced DevOps, then this transformation will be much easier. Telling the DevOps team that the security team is going to stop putting gates in front of them all the time, that they will provide security feedback earlier and more often, and that the security team wants to work with them would be a dream come true for many organizations.
No matter what the current SDLC (Software Development Life Cycle) model is being used, education for everyone involved will help overcome both technical and cultural barriers.
DON’T MISS Developers still struggling with security issues during code reviews, study finds
DS: Your company, We Hack Purple (WHP), offers training in DevSecOps. What kind of infosec professionals is the training aimed at?
TJ: We Hack Purple offers on-demand virtual training, which is taken by all sorts of people: project managers, developers, AppSec folks, and quite a few people switching from entirely different careers such as nursing or teaching. WHP has put a lot of work into being diverse and inclusive to attract a wide range of students and community members.
Diversity, inclusion, and accessibility have been three of our six core values since the start. This has resulted in significantly more women, people of color, disabled people, and people from underrepresented groups deciding to attend our academy and join our community. We are very proud of this achievement; creating a safe place for everyone to learn.
Since the acquisition of WHP by Bright Security, WHP no longer offers live virtual training, but I still find the time to do some on the side – 66% of the time, services were purchased by the security team, either for the developers or the security team itself. One-third of the time, I’m hired by developer teams who feel the security team is failing them, and they want to take over AppSec responsibilities for themselves.
DS: What are some of the hurdles you come up against when training people to have a DevSecOps mindset?
TJ: A very interesting scenario is when a dev team hires me, in secret, and I have to help them learn and perform AppSec themselves, under the security team’s radar. This might sound kinda strange, but it’s (unfortunately) more common than most people realize; a lot of security teams fight against developers taking control over the security of their software.
They fear if they give them tools, the developer “will hack their organization” or “become malicious”, which is ludicrous! A malicious software developer is any organization’s worst nightmare; they are all already hackers and could do intensive damage if they wanted to.
Giving developers a DAST scanner or another security tool will not change their ethics. It’s the same as giving someone a hammer; they aren’t about to [just] start hurting people with it.
Read more of the latest DevSecOps news
DS: Can you tell us about your new role with Bright?
TJ: I am leading the developer relations effort at Bright. I was previously their advisor, so I was already providing product feedback, general advice, making introductions, and occasionally creating content. Now I do all that full-time, plus I manage a small team, which means a lot of mentoring (one of my favorite things!).
I have a total dream team, people who love to create content, some of whom I brought with me as part of the acquisition and some of whom I have hired since I arrived. With the support of Bright, I’m able to speak in person at many more places and conferences than I have in recent years.
DS: What are your plans for the rest of 2022, and are you working on any upcoming projects you can share details about?
TJ: I travelled to Europe for the first time since the pandemic for Sec4Dev in Vienna. I’m also working on several events for women and all other people from underrepresented groups in tech. Lastly, but certainly not least, I have just signed on to write my second book, Alice and Bob Learn Secure Coding, which should come out in December 2023.
YOU MAY ALSO LIKE ‘We’re still fighting last decade’s battle’ – Sonatype CTO Brian Fox on the struggle to secure the neglected software supply chain
