Builders vs Breakers: Bridging the gap Between Software Development and InfoSec with Tanya Janca

Application security testing and assessment commonly occurs toward the end of the standard software development life cycle (SDLC). During this time, code reviews and penetration tests are done to ensure no security flaws or bugs are found in the application before it moves on to production. As much as penetration testing and code reviews are an important part of any application’s security process, they are typically done too late.

To truly develop secure applications, security must be ingrained into every phase of the SDLC. Since the beginning of software development, application security has mostly been disjointed from security, creating one of the biggest challenges in information security as a whole. Tanya Janca, a software developer with more than 15 years of experience, knows this best.

Tanya has had a multi-hatted role throughout her career. She started working at a young age as a software developer, and found her way to security via penetration testing and vulnerability assessment, after more than a decade in the industry. She now takes on the role of an “AppSec evangelist.” Tanya has made a large and positive impact on our industry as a passionate and talented former OWASP chapter leader, and now as a public speaker, trainer, and mentor.

We had a chance to chat with Tanya about her background, how she shifted her mindset from builder to breaker, why you should never go with the top answer on StackOverflow, what being in the hardcore punk scene taught her about infosec, and more.

SecurityTrails: You started coding really young, at 16-17, and continued doing software development for 16 more years. What has swayed you to security and pen testing? How did you change your mindset from someone who creates/builds code, to someone that breaks it?

Tanya Janca: After being a senior dev for a long time, management was trying to push me into management. They kept pushing me, over and over. Apparently, this is common for senior women devs. I was not interested in management. I had tried it a few times and it made me miserable. Then I met a penetration tester and we became friends. After constantly showing me new hacks and defenses, sending me texts, articles, and books, and directly hacking one of my apps, he eventually convinced me to become his apprentice and learn about security. He was very persuasive.

I learned a fair amount of thinking like an attacker by sitting in on threat modelling sessions, listening to podcasts, and reading everything I could get my hands on. It took a while for me to be able to see things consistently from that angle. It’s difficult to switch your mindset from “how can I make this work” to “how can I make this work in a way that it is not supposed to.” But DAMN it’s fun!

Would you say that having a background in software development has made it easier for you to transition to security, rather than doing it the other way around?

Tanya: Yes. Having a background in application development, I always understood where they were coming from, what they needed, and how software works. Understanding the software development life cycle (SDLC) is essential if you want to work as an AppSec engineer. That said, I do believe you can learn enough about software development to work in AppSec without needing to work in dev for several years or have a computer science degree. You just have to work harder at it.

As for moving from security into development, that would depend 100% upon which area of security you were working in. If you were a risk analyst, you would likely need to start from scratch learning to code. However, if you worked in AppSec, then you would need to learn a lot less. Perhaps starting with a coding bootcamp would be enough for an AppSec engineer to change over to a full time programmer.

When did you figure out that you are here to stay (in security)?

Tanya: What an interesting question, I never really thought about it. I guess it was when I discovered I could do AppSec and that it was a job, and not just do penetration testing (which I felt unsatisfied with and didn’t want to leave until everything was fixed). That’s funny, I guess that was it. When I found out AppSec was a job that I could have, I knew I was in the right place.

I’ve heard that you’ve been doing music for quite some time. Has playing music and being part of a punk scene taught you some things you were able to translate to your career in tech?

Tanya: I definitely think so. It helped me learn to handle difficult people, which I rarely had to do as a software developer. I have found a minority of people in the security industry to be significantly more abrasive than those in programming. It also helped me learn how to run my own (somewhat profitable) business, demand payment when necessary, and get work (which is great for being a security consultant). I also know how to throw a drunk person off a stage, though I’m not sure if that applies to InfoSec or not yet.

You were an OWASP chapter leader in Ottawa. Can you tell us a bit about that experience, and how it influenced the direction you took your career in?

Tanya: Being an OWASP chapter leader was very rewarding. I got to meet hundreds of people, and as an extrovert that’s a huge plus. I often had the chance to choose the speakers, topics, activities, and events. I have always enjoyed building communities, and OWASP was a chance for me to do that as part of my professional life. I also learned so much. Not just from the talks I watched, but from informal discussions, meeting up for coffee with people from the community, and building my own talks and research. The community in Ottawa was so incredibly supportive of me joining InfoSec, right from the very start. I realize that not every OWASP chapter is like Ottawa, but I couldn’t imagine what my career would be like without having had them in my life.

As someone who’s been a developer since the late 90’s, how would you say the concept of application security awareness with software developers has changed since then, if it even changed?

Tanya: When I started programming, security wasn’t even a thing. I went to college and that topic never came up, unless you count learning Novel Networking systems and how to give users access to your network. I am told time and again by current students and recent grads that the situation has hardly changed at all. They all communicate that they do not feel prepared to ensure the software they create is secure.

How has it changed? It exists now; it’s on everyone’s radar. Also, the maintainers of several programming frameworks have added and improved their security features. Each year programming frameworks are becoming more secure by default, meaning the developer doesn’t need to learn anything new. I feel like application security went from something no one ever thought about to something that is, at least a little bit, on every person’s mind now.

I should note, I’m biased. The developers I talk to are usually talking to me because they want to learn security. Maybe I just hope it’s on everyone’s radar.

What are some challenges that organizations experience when thinking of adopting application security and shifting security left, and what are some for developers?

Tanya: Challenges for organizations are – having a budget, being able to recruit and keep talented staff, knowing where to start, and what the steps are.

Challenges for developers are – security training is usually exponentially more expensive than dev training, their security teams don’t have any AppSec knowledge and therefore can’t help them, documentation and guidance about security is not always available, and they are often not given extra time in project schedules to participate in security activities or fix the bugs that result from those activities.

Why do you think security is such a stretch for developers?

Tanya: Because it’s really, really hard. Securing software is genuinely difficult, because most developers have had very little, or zero, security training, and are then expected to “just know.” I have a lot of empathy for devs whose management won’t pay for training, but then blame them when there are security issues.

There are development practices that can help developers turn into “security people”. Which ones do you think are the first steps? How can we help our developers think of ingraining security into every step of the process?

Tanya: The first thing every developer should do when they go to look up something they don’t know how to code, is look for the most secure way to do it. The top answer on StackOverflow is often the least secure way for whatever you are trying to do. Making this little change can have a huge positive impact on your code quality.

As to where they should start learning about secure software, I created a blog post of all free resources on the topic. My 4th edition of the list is here.

With DevOps, organizations are experiencing improved speed and flexibility when it comes to software development. But how can we bridge that development gap between speed and efficiency, and security?

Tanya: Security must adjust for DevOps, or we will be left behind. If our developers are sprinting, then we must change our security activities so they fit into sprints. If the operations team is using infrastructure as code, then we must do security as code and learn how to validate their infrastructure as code, in order to verify it is secure. We have the same goals, we just need to work towards them differently.

I feel as though many security professionals feel that the rest of tech must work around us and our needs, but the world is not like that. Business (and capitalism) is not like that. We all need to accomplish our mandates. Security needs to achieve their mandates in new ways, with different or changed activities.

Here are a few concrete examples of changes that could help in a DevOps environment:

• Add Software Composition Analysis (SCA) to your pipeline, and also set it up to auto-scan all of your repositories once a week. SCA verifies that your 3rd party software components are not known to be vulnerable. This will protect legacy apps and make sure you don’t accidentally introduce new components, that are known to be vulnerable, into your prod environment.
• Create unit tests out of your penetration test results, to ensure you don’t re-introduce the same errors. Also, take those results and make unit tests for ALL of your apps. The same programmers made other software in your company, and likely made those same mistakes.
• Scan for secrets in all of your pipelines, break the build, and initiate an incident immediately if the secret was checked into your source code.
• I have a zillion more ideas on this topic, but I don’t want this interview to be 100 pages, so I’ll stop now.

If this topic interests you, you can start learning about it with my talk “Security Learns to Sprint: DevSecOps”:

You are in the process of writing a book. Could you tell us a little bit more about it, what you’re writing about, and when can we expect for the book to see the light of day?

Tanya: My new book is called Alice and Bob Learn Application Security. It will teach the foundations of application security, as well as dip its toes into a few other areas of security. The characters, Alice and Bob, are often used as examples throughout the security industry, since they were first used to introduce and explain what an SSL handshake was. In my book, Alice and Bob have lives, health problems, and jobs, with stories to illustrate how various security concepts or controls affect real people’s lives. The book is an unusual textbook, written in casual language, with stories, analogies, diagrams, and the lives of Alice and Bob to relay the information. It is my hope that it will be adopted as a textbook for computer science classes. It’s all the things I wish programmer graduates would know.

I hope for the book to be ready in the fall.

One more thing you are working/worked on is your new learning platform — SheHacksPurple.dev! What was the motivation behind starting this project and what will you be teaching us?

Tanya: My motivation for starting SheHacksPurple.dev was to bring more people into our industry, and get them working as competent and trained security professionals. Right now, we have a large problem with recruiting qualified candidates for various jobs in information security, with application security and DevSecOps being extra-difficult to find. I’m creating affordable training courses (<$99) and content ($7/month) with the goal of teaching people exactly how to do the jobs they want.

When I look around our industry, I see a lot of training priced at a point that is unobtainable for most or random hacks that don’t help you do your job, and usually concentrate on open source products that one would rarely use in a production environment. I have yet to see training that would teach you how to be an application security engineer. Note, that does not mean it does not exist.

My courses will concentrate on why you want to do specific activities. For instance, when should you do SAST, what types of metrics to track, or when it makes sense to get a WAF versus a RASP, as well as hands-on activities to give one a chance to train on real tools that are popular in our industry. Everyone wants to hire someone with experience. I’m hoping to give participants hands-on with tools they will find in production environments.

I’m also hopeful that once I have released a complete program of study, I will make enough money to create a job placement program; paid internships, co-op placements, or facilitating entry-level interviews. Once someone is in their first job, the rest is easy. If I can place most of my graduates in their first job, I would consider that my highest goals successfully achieved.

If I can do this, I feel it would make a large and positive impact on our industry. And that’s what I want – to help, at scale. Wish me luck, I always set huge goals.

As someone who always has a few projects you are working on simultaneously, how do you stay focused and see them all through the end?

Tanya: With me, I never have a problem feeling motivated. I love what I do, except when I have to read contracts, do my taxes, and book edits. My problem is allowing myself to become distracted by other things that also sound amazing. When I’m invited to speak somewhere, I always want to say yes. When someone asks for help, I always want to say yes. I need to learn the word no. I have a few people in my personal life helping with that, and I just hired my first part time employee who will also help with that. Once we have enough cash flow coming in, I plan to hire a full-time employee to 1) do the administrative stuff I don’t enjoy and 2) make sure I say, no, more often and/or say yes, but ask for money (I’m bad about doing things for free).

Industry conferences are no strange playground for you. For the end — tell us about your favorite moment/experience from when you spoke at cybersecurity conferences?

Tanya: My favourite moment at a conference was when I announced my startup last year. I did my bio and announced I was the CEO of my new security company, and the audience stopped me from continuing the talk. They started applauding, screaming, and taking photos. I am shocked I didn’t start crying, it was so touching. The support I have felt from the InfoSec community and industry, over and over and over again, is so powerful. I feel gratitude, on a regular basis, for how wonderful our community has been to me. I count myself lucky, as I have certainly found my professional place.

Make sure to visit Tanya’s amazing new platform, SheHackPurple, and check her out on Twitter to follow along with her numerous workshops, lectures, and funny, offbeat commentary on our industry and everyday life (her account is one of our favorites).

In time of social distancing and #stayingathome, for this interview we weren’t able to have a photoshoot with Tanya, but we hope you enjoyed nonetheless as we are always driven to provide valuable content.

How are you enjoying the new cybersecurity interviews we have done this year? You can check our previous interview with Biella Coleman to see us dissect hacker culture and its origins.