Optimizing Team Communication With Sara Dunnack

"Sara Dunnack: All the engineering teams know that we don't want security to be a blocker. We're not putting ourselves in the critical path. We want to work with them. Not against them. And that's definitely helped us maintain that good security culture. It's a "help me, help you" situation. And it's so far worked really well. "And I don't see it changing anytime soon."

"If you want to level up security, especially on the AppSec side, stay in development as much as possible. I think when you get to the infrastructure world, you get to a point where you're like I want to start breaking things." 

[00:00:33] Guy Podjarny: Hi. I'm Guy Podjarny, CEO and Co-Founder of Snyk. And you're listening to The Secure Developer, a podcast about security for developers. Covering security tools and practices you can and should adopt into your development workflow. It is a part of the Secure Developer Community. Check out thesecuredeveloper.com for great talks and content about developer security, and to ask questions, and share your knowledge.

The Secure Developer is brought to you by Heavybit, a program dedicated to helping startups take their developer products to market. For more information, visit heavybit.com.

[INTERVIEW]

[00:01:07] Guy Podjarny: Hello, everybody. Welcome back to The Secure Developer. Thanks for tuning back in. Today, we have Sara Dunnack from InVision. Welcome to the show, Sara. 

[00:01:14] Sara Dunnack: Thanks for having me.

[00:01:15] Guy Podjarny: Sara, before we dig in, can you tell us a little bit about yourself? What is it that you do? And how you got into the world of security?

[00:01:21] Sara Dunnack: Sure. I do application security at InVision. And it's definitely evolved throughout my career. I started off as a classic ASP developer. That's definitely dating myself. From there, I went into web engineering. And I think when you get to the infrastructure world, you get to a point where you're I want to start breaking things. That's how I came into AppSec. 

[00:01:44] Guy Podjarny: Yeah. Interesting kind of impulse there. 

[00:01:46] Sara Dunnack: Yeah.

[00:01:48] Guy Podjarny: And that's all kind of within InVision? Or is that in different companies? Big? Small? 

[00:01:52] Sara Dunnack: No. Right out of college, I went to a small design firm, which might use InVision now as a tool. From there, I went to a large insurance company. Got into web engineering there. And into security. And when I came to InVision, I've been on the AppSec team the whole time. I was actually the first security hire for the company outside of the VP. 

[00:02:14] Guy Podjarny: How many people were roughly in the company at the time? 

[00:02:17] Sara Dunnack: I was employee number 150. 

[00:02:18] Guy Podjarny:150. Okay.

[00:02:19] Sara Dunnack: And we're over 800 now.

[00:02:21] Guy Podjarny: Yeah. Well, that's a good-sized company.

[00:02:22] Sara Dunnack: Yeah. When I got to InVision, I did pretty much everything. Customer questionnaires. Talking to the customers about our security. Didn't do so much on the DevSecOps side because we have our own DevOps team there. We do have a security DevOps team now. But, yeah, now I'm focused more on AppSec again.

[00:02:46] Guy Podjarny: Got it. Okay. Let's indeed sort of dig into those. I mean, this sounds like a journey. And it's interesting. It's always interesting to grow with a company. You sort of had a one-person show earlier on. How does indeed then the team look like right now? Roughly, how many people do sort of security on the team? And how is it divvied up?

[00:03:06] Sara Dunnack: I think we're about 15 people now. And it's split up amongst the compliance team, the DevSecOps team, and AppSec. 

[00:03:15] Guy Podjarny: I think compliance, I understand, sort of its own run. What's the difference between the DevSecOps team and AppSec? 

[00:03:22] Sara Dunnack: DevSecOps definitely focuses more on the infrastructure side and not so much on the application side. They handle our web app firewall. Hardening any images that we might need? And, basically, just do anything that you'd think a regular DevOps team would do but very security-focused.

[00:03:40] Guy Podjarny: Okay. Interesting. But more sort of infrastructure-oriented. And the AppSec side? 

[00:03:47] Sara Dunnack: AppSec side does any kind of testing within our actual application. Mainly our customer application. We do security reviews. We manage tooling such as dynamic scanning, source code analysis. We build our own tools to do some linting and other things like that. And we are the main team that interacts with the engineers in order to make our code more secure. 

[00:04:14] Guy Podjarny: And how often or how easy is it to maintain that split? I mean, as kind of a lot of software becomes software-defined and maybe there's some Terraform script, or some Helm chart, or whatever it is on some repository, does it come up at all this division of responsibility? Like engineers dealing with something that is infra and that's suddenly sort of the DevSecOps team? Or does the split work fairly smoothly? 

[00:04:41] Sara Dunnack: For us, it works very smoothly. All the roles are defined. And engineering doesn't really come to AppSec for any of that stuff. Even the WAF, they all know to go to the DevSecOps team. We call it security SRE. For us, it hasn't been an issue.

[00:04:58] Guy Podjarny: Interesting. And so, I mean, I think that's a really – I love the model because it reflects. I generally really like DevOps analogies as we dig in. Let's sort of dig deeper into your neck of the woods here with AppSec. 

We talked before about how you as an application security team work with engineering. Can you describe that a little bit? How do you engage with the engineering teams? 

[00:05:25] Sara Dunnack: One thing that we implemented recently was we have an AppSec person kind of aligned with all of our engineering teams, especially the ones that do development. We have roughly 40 different teams that do development. Because we do microservices. Teams are split up specifically for a specific function to provide code on one part of the app. 

And what that's really helped us with is communicating openly with the engineering organisation as a whole. For instance, I attend stand-ups almost every day. I try to hit two a week. Because some of them do overlap on time. But I attend stand-ups for the team so I know what's going on. And I actually participate in the stand-up with them. And, also, I'll take time if there's any projects that we're working on, any kind of functionality we might roll out that might affect them, I make sure to give them a heads-up as soon as possible so they're never going to be surprised by it. And it really helps us not be a hated team. Because security –

[00:06:35] Guy Podjarny: Sometimes seen as the naysayer. Not necessarily the one you want to call to the party. Yeah. 

[00:06:37] Sara Dunnack: Right. You don't want to be a blocker. It's really helped us in terms of opening the line of communication and getting a better relationship. 

InVision is a very strange company in that security isn't thought of as an after-the-fact. If we tell the team that there's a vulnerability, we don't get pushed back. We don't get told, "Oh, that's going to take 3 months to fix." Depending on what it is, especially if it's like a critical or high, it's fixed the next day. If not that same day.

[00:07:08] Guy Podjarny: It's amazing.

[00:07:08] Sara Dunnack: Even on a low. We don't get any pushback. 

[00:07:12] Guy Podjarny: Any pushback at all? Well, first of all, amazing. Great job. And definitely, probably one that you've had as kind of an early security person in the company, kind of had a good success, I guess, building that up. How do you – I guess I'm still on the sort of the alignment bit. Although, now I'm super intrigued by this achievement of getting people involved. 

If we go back to this alignment, I mean, how do you divvy it up? You're aligned with a bunch of these groups, right? And you work with them. You attend their stand-ups. You're pretty embedded, I guess, inside the relevant engineering teams that you align to. Do you aim for a certain ratio? Or how do you decide how to maintain that over time? 

[00:07:57] Sara Dunnack: What we do is there's four of us. Not including our manager. And we've split it for the most part evenly. But it is also based on position. If you're like a higher title, you'll be responsible for just a few more teams. 

[00:08:14] Guy Podjarny: You might have more capacity.

[00:08:15] Sara Dunnack: Right. We do it that way. But on average, everyone has somewhere around 10 teams, which is working out well for us. And it's divvied up by our engineering or kind of has zones for different functionality types of the application. Each AppSec person might have a large part of a particular zone and all the teams under that zone. That's one easy way to split it up. 

[00:08:41] Guy Podjarny: To map it. Okay. I get it. That makes a lot of sense. You're basically aligned with the way that the teams are split in the first place in the development organisation. And you map with them. I guess InVision is a very distributed company. This isn't about collocating with the teams. The relationship ship is still virtual, I guess, as is the relationship between all employees in InVision?

[00:09:04] Sara Dunnack: Yeah. We are a 100% remote organisation. We have no offices. If we do have an office space, it's in WeWork. I think with us using Slack and every meeting is a video call over Zoom, you don't really feel disconnected from the rest of your organisation. Because you still see people on Zoom. 

For instance, if we have an offsite and I see someone on my team that I've never met in person but I'm good friends with them at work, I'll run to them, give them a bear hug when I first see them. And it's a very different company than most in that we have no ego. We don't hire people who have egos. And we're a big family. 

[00:09:52] Guy Podjarny: Yeah. I'm a big fan of InVision. As a company, as a culture, definitely sort of one that I look up to. But you're just sort of giving me another reason to like InVision in this sort of security mindfulness if you will, or awareness. Let's sort of dig into kind of this wonder. How do you maintain that? How do you celebrate successes? What do you find helps you keep that approach up? Do you encounter at all pushbacks from developers? Or is it literally just, "Hey, we've built the culture. And now it just kind of runs itself around people responding and thinking about security problems as we go?" 

[00:10:34] Sara Dunnack: The only time we've really had pushback is if there's a very tight deadline and they'll say, "Well, can we put it off to like a couple sprints from now?" That's pretty much the only "pushback" that we'll get. But even still, no one will fight us on making any changes really. 

And I think we've been able to maintain that as we've grown through good hiring. And we make sure that all the engineering teams know that we don't want security to be a blocker. We're not putting ourselves in the critical path. We want to work with them. Not against them. And that's definitely helped us maintain that good security culture where they know that we're not out to get them. It's a "help me, help you" situation. And it's so far worked really well. And I don't see it changing anytime soon.

[00:11:24] Guy Podjarny: Let's sort of understand a little bit the relationship of who does what. As you talk about, either the DevSecOps team, or the AppSec team, and the engineering teams. Who implements security solutions, or sort of runs them, or, I don't know, deals with the vulnerability outputs? Are these things operated by the security teams? Are they operated by Dev? How do you decide those? 

[00:11:49] Sara Dunnack: For the most part, anything security-related will be done by the security team. There are some instances where teams have said that they want to have GitHub integrations that have a security impact. They'll do that on their own, which is great that they want to take that initiative. And we do have engineering teams come up to us and say, "Oh, hey, I found this in our code. We're going to fix this. We're just letting you know as an FYI." 

[00:12:18] Guy Podjarny: And do you have like a standard way of sort of celebrating that or acknowledging? 

[00:12:22] Sara Dunnack: We want to make T-shirts and give out T-shirts. For instance, the T-shirt I have today, on the back of it, it just says rockstar. And we would love to be able to do that and give that to them. But another thing that we do as a company is something called Bonusly, where you give peer dollars to each other for a job well done.

Probably, the main way and certainly the easiest way for us to do that would be to give a person Bonusly if they tell us something or if they – we do that even if someone gives like a really good talk during like architecture office hours or something like that. It's celebrated in that the organizer will be like, "Hey, so and so did a great job. Shoot them some Bonusly." And it really encourages people to keep staying involved and strive to help the organisation get better.

[00:13:14] Guy Podjarny: Yeah. I mean, it's interesting that in most companies, generally, you try to get developers to care about security. When you're in a really good place like you are, you almost need to be careful not to overly rotate on the sort of cognitive dissonance side. If you start compensating or overly rewarding for it, people might start thinking about this as an exterior motivation for doing the good job. Well, right now, it sounds like they're addressing it as something more internal, more intrinsic to building kind of good quality software.

[00:13:45] Sara Dunnack: Yeah. They've asked us if we would have an internal bug bounty program for finding and fixing issues. And we keep pushing back against that because we don't want them to purposely write bad code to help their friends out to get money. We're holding off on that. I think that'd be a little overkill.

[00:14:01] Guy Podjarny: I think that's wise. I've actually heard – it's not the first time I hear that. But people consider. It's like, "Okay, you can't report vulnerabilities from inside when you're the one who might be writing in." 

[00:14:11] Sara Dunnack: Right. I mean, there definitely have to be some rules around, like some guidelines around it. But I don't think that's anything that we'll implement anytime soon.

[00:14:20] Guy Podjarny: Maybe we'll talk a little bit about a few practices that you have given this reality or sort of tight relationship with Dev. How do you handle sort of security training in the organisation? 

[00:14:32] Sara Dunnack: We do have specific modules that developers have to take for compliance purposes. Actually, our OKR – it's funny that I mentioned this. Because we didn't talk about this beforehand. But our OKR this quarter is to essentially start from scratch. And the AppSec team is going to write the training documents. So, specifically tailored towards our environment. And it's aligned with ASVS point. We're starting from scratch and really tailoring it. Because one thing is the technologies that we use don't have a lot of documentation, especially around security. It's been a pain point of ours, which has led us to focus on creating all this documentation this quarter.

[00:15:18] Guy Podjarny: Yeah. And it makes sense. I think it aligns with how you described it before as well on the security team as an enabler and kind of helping developers do their job. This is one that you'll do. I guess if you write it from scratch or not, modern tech is hard. Sometimes you have to do more if the ecosystem hasn't caught up.

[00:15:36] Sara Dunnack: Yeah. It's definitely nice. Because we've been asking the engineering org for feedback and what they want to see documented so we can really focus on what they think that they need help on and where they might be having more issues. It's definitely going to be I think good for us overall.

[00:15:53] Guy Podjarny: Have you encountered any cases where there was a bit of a conflict between the need of security and the need of Dev maybe even because of this relationship? Cases where you wanted maybe to introduce a specific solution and there was too much Dev friction so you had to almost give up on the security side? Or has it ever come up as a challenge matching up the sort of the priorities on the security side and on the Dev side? 

[00:16:20] Sara Dunnack: Not really. I think the most pushback we've gotten is if we're trying to roll out a new tool and it would possibly impact the engineering teams. What we've been pretty good at doing is getting them involved in the POC so they can give us feedback on that. And there have been a couple of tools that we were very close to signing with and then we got the engineers involved and they're like, "No. Please don't."
[00:16:44] Guy Podjarny: I'm not going to do this. Yeah.

[00:16:46] Sara Dunnack: That's probably the most we've gotten real pushback on. Like I said, InVision is just strange in that we don't get the pushback typically. 

[00:16:54] Guy Podjarny: That's wonderful.

[00:16:56] Sara Dunnack: AppSec-wise, there hasn't really been pushback. But I think there's been pushback on like the DevSecOps side, security SRE side with turning off or enabling certain features and not being able to do that quite yet. That would probably be the biggest pushback. It'd be mainly configuration changes to perhaps specific tools or the environment itself. I think our SRE side has probably had more pushback than AppSec. 

[00:17:23] Guy Podjarny: Yeah. Interesting. It's more because they apply constraints. And those constraints might be a little frowned upon. But they might be necessary.

[00:17:32] Sara Dunnack: Yeah. I wouldn't even say frowned upon. It's understood that these things need to change. But it just might take some time to get there.

[00:17:40] Guy Podjarny: Got it. To sort of build the right sort of secure configurations or frameworks to allow developers to tweak, and modify, and use those technologies or those configurations without compromising security. 

[00:17:50] Sara Dunnack: Right.

[00:17:51] Guy Podjarny: Okay. Interesting. Is that DevSecOps group also aligned like you are on the AppSec side? 

[00:17:58] Sara Dunnack: They're not. I mean, they'd be more aligned with the platform engineering teams. But I don't think they have a one-to-one like we do. Because, we're even aligned to a degree with the platform engineering teams as well and performing reviews for any code that might touch production or handles the build platform. We still need to look at all of that as well.

[00:18:21] Guy Podjarny: Got it. First of all, this is excellent. And I think all the part to you for sort of being in the state and getting to this great relationship. I think for all us commoners, if you have sort of some good tips, if you're sort of talking to a team that is looking to level up their security foo, whether it's on the Dev side or the security side, what would be sort of you know one tip you have or maybe like a pet peeve of something you see people doing wrong that you would share to sort of help just move up the journey of doing security better? 

[00:18:55] Sara Dunnack: One tip I would have is something I'm working on myself where I've been out of development for so long. If you want to level up security, especially on the AppSec side, stay in development as much as possible. Because if you need to do code reviews, it certainly helps if you are still in the mindset of regularly reading code. Everyone on our team is really developer-first and security-second. Obviously, strong security. But we need to be in the code. That's one thing that we do. 

For our security reviews, we actually do full code reviews. I think that's the biggest thing that many security folks may not think about, especially if you come from like the sysadmin side, is you need to be able to get into the code and truly help the developers and show them the specific line. Like, on this line, you need to do this.

[00:19:48] Guy Podjarny: Yeah. No. That's really good advice. It's just a very relevant skill. You have to understand the material. The thing that you're reviewing. I think that's sound advice. And I think one that hopefully more and more security teams are getting but still need to keep improving on. 

Well, Sara, this has been a pleasure. Thanks for coming on the show. 

[00:20:08] Sara Dunnack: Thanks for having me. 

[00:20:09] Guy Podjarny: And thanks everybody for tuning in. And I hope you join us for the next one.

[OUTRO]

[00:20:14] Guy Podjarny: That's all we have time for today. If you'd like to come on as a guest on this show or get involved in this community, find us at thesecuredeveloper.com or on Twitter @thesecuredev. Visit heavybit.com to find additional episodes, full transcriptions, and other great podcasts. See you next time.