EP 26 — Derek Fisher: How Envestnet Scales Product Security

Harshil: Welcome, everyone, to another episode of the Future of Application Security. Today we have Derek Fisher with us. Derek, welcome to the show.

Derek: Hi, thank you for having me on, and I'm looking forward to the conversation.

Harshil: Derek, it is a pleasure to have you on this episode. I've been looking at some of your podcasts and some of your books and content and articles that you've been publishing. I'm really looking forward to this conversation. I love people who have educated opinions, so it's going to be great. Before we dive in, I would love to have you introduce yourself to our audience. What do you do, where do you work at, what are you passionate about?

Derek: Sure. I work at a financial technology company called Envestnet. We're a large advisor organization, so we create software for financial advisors. We also do some data aggregation work as well in the financial industry. Obviously we have a lot of concerns around security when it comes to that type of work. I've been in engineering for going on probably about 30 years now. I started out in hardware engineering, moved into software engineering, eventually got into cybersecurity about ten years ago, and have been in application security ever since. So I teach at Temple University. I've been doing that for several years now. I teach a software development security course there. I've written a book on building an application security program, written a children's book series on cybersecurity as well. A lot of what I try to do and my passion, I suppose, is really trying to engage others in security. One of the things that I think has become very relevant, at least in application security and at least in my experience, has been the fact that no matter how large my team is, it's never going to be large enough to cover the space that I need. The majority of my job and a big priority in my role is really to raise the security awareness of everybody else around me. Because when I'm working with engineering teams, their ability to be able to code securely means that my team and myself have to spend less time doing that work. It's really a way for us to kind of spread the wealth. That's why I'm kind of passionate about raising the security awareness of others.

Harshil: Talk about shifting left and raising security awareness, you went all the way to children's books, right? That's real shifting left.

Derek: You know, I have a daughter, she's twelve. When I first started writing the books a few years ago, she was about the age that I was kind of targeting with the books. It's interesting to see when I grew up and when many of us that are kind of in this business and have gray hair and stuff when we grew up, we didn't grow up with devices in our hands. That has fundamentally changed today. You know, children, even ones that are preteen and younger, all they know is technology. It's around them everywhere. I think it's on us in the security space to really help raise that awareness of not just the children, but also parents, because those of us that are in specifically cybersecurity, but even technology, we kind of know. We know what the dangers are, we know what the risks are, and we have a good idea of how to really put controls in place. But I think there's a lot of parents out there that don't know that. I think for those of us that can provide that help and that guidance, I think, is critical to really help because there's true dangers out there. There's a lot of real world implications for misuse of technology, and kids are especially prone to that.

Harshil: Right, right. Since you also teach at Temple University, have you seen a shift or change over the past few years in terms of people's interests in cybersecurity?

Derek: I have. It's funny, when I first started teaching at Temple, the individual that introduced me to Temple and brought me in, they brought me in just as a speaker for his particular course on quality assurance. I did a night each semester in his course to talk about security as part of quality assurance. And we started having conversations about maybe this is somewhere that Temple might want to have a course on software development security. And I remember the gentleman that brought me in said, "Nobody's ever going to sign up for that course. It's like, nobody cares about security. It's going to be boring. You're going to get two people to sign up". And since I started the class has always been full with a waiting list. And actually last semester and this semester that we're currently in, I've had to expand to two sections. Now there's two classes being taught each semester, and both of them are at capacity with a waiting list. So to me, that shows a good, either I'm an easy teacher and everyone wants to join the class because it's an easy course, or I'd like to think that the students are really getting something from that. And one of the things that I often end the course with is that I try to impart to the students that there's a lot of students leaving, particularly software engineering type of degrees. There's a lot of students that are graduating with that. And in order to set yourself apart, you really have to have a niche. You really have to have something that's going to kind of make you stand out from the other hundreds of engineers that you're going to be competing with. And I think as organizations mature and as we obviously see the impacts security and understanding that security has a real place at the table in terms of technology, being able to go to an interview and say, "Hey, I understand security, I understand what basic concepts of security are, and I understand how to stop SQL injection, and I understand what parameter tampering is and how encryption works" and things like that. Those are going to set you apart from the people that the others that you're competing with. So I try to make sure that students understand that.

Harshil: Right, that's awesome. Somebody graduates with taking your course, how employable, I guess, are the skills? Is the learning curve significantly higher when they look for a software security role, or that sets them up on a much easier ramp? What's your thought on that?

Derek: Yeah, I remember stating on several occasions, like in my course, that you're not going to walk out of here and become a pen tester. You might if that's really where your passion is and that's really where you want to follow, but the purpose of the course that I teach is really to get those foundations spilled in. So basic understanding of the CIA: confidentiality, integrity, availability, the basics of what encryption is and how it works, and hashing and why we use it ,and the OWASP top 10, doing basic threat modeling, risk assessments, understanding what a secure software development lifecycle looks like. I think all those things are relevant for anybody that I would be hiring for my team is an understanding of those concepts. And put in perspective, I have hired two students from Temple University into my team over the past year or two. So some of those skills are very relevant to being able to get at least an entry level job in a security engineering type of role. What I look for when it comes to an application security engineer is really an understanding of how software gets built. Because I can teach you security or anybody can teach you security, it doesn't have to be me. You can learn security over time. You'll get it, you'll understand it. I think being able to understand how software gets built, how it gets delivered, how it gets deployed, how it gets maintained, those are skills that I think you need day one. Because the individuals that we work with, we can run tools, I can get operators to stand up tools and get reports and give those to development teams, but if you don't know how to put those results from those tools into the context of the application and understand what it takes to actually remediate that problem, then you're not really being helpful, right? So I think those skills of understanding how software gets developed is fundamental along with security.

Harshil: Yeah, that's definitely very important. Now, in addition to teaching at Temple. You also have your own podcast. You talked about children's books, the AppSec Program Handbook that you published as well. You teach at Temple and you have your own podcast. Talk to me about the podcast itself.

Derek: Yeah. So I started the Application Security Program Handbook published by Manning, it came out in December. You can get it on Amazon and Manning.com. And so, the podcast was really to kind of take some of the concepts from that book and put it into audio format. If you go see it's called Masterpiece Security. My intention with that is really just to be a little silly and over the top with it. If you haven't seen it already, I wear, like, the lounge bathrobe and slippers on, and I'm sitting by a fake fireplace. Anyway, it's supposed to be a little silly, but at the same time, I want to talk about some of the concepts in the book. And it's meant to be short, engaging, and not the, "Here's my book and here's why these things are important". It's hopefully a little bit more fun. But my friend who's the one that got me into Temple, he sent me a text the other week and he said, "How many of those videos are you going to release? And I was like, "I have content for the entire year, so brace yourself". But I think to me, it's kind of a fun way and silly way of kind of hopefully making it more engaging and not as dry as death by PowerPoint, as I like to say.

Harshil: Right, right. So I'm sure in your role you'd be facing a lot of the challenges that you're trying to solve, you're talking about how to solve those problems. What motivated you to write a book and do a video series on it?

Derek: I started writing the book in I guess it was early 2021, and this was deep into the pandemic and we all had a little extra time on our hands because we weren't commuting, weren't out and about as much so we had a lot of time on our hands. I had been kind of tossing around some ideas about I had already written the first children's book. I was starting to write the second one. I started thinking about, can I document my journey in application security? Because I think the things that I've learned and have seen and the pains that I've gone through and the things that I've done and where I've seen things work and not work, I think that's relevant to not just myself, but to others. I started thinking about, is there a way for me to really document this and make it available? And it just so happened that Manning Publishing had reached out to me and said, "Hey, have you ever thought about writing a book on application security?". I was like, "I actually have". So the stars kind of aligned there. I'm thankful for Manning, for reaching out and helping out in terms of getting the motivation there. Because if you haven't written a book for a publisher yet, it's challenging. You're under strict deadlines, y. You have deliverables, and they have people that keep you in check. It's work, and it was a lot of work. I'm glad that so far there's been a lot of positive feedback on it. I think there's been a lot of people that have found the value in it. And again, I'm glad I can impart that because I think for those of us that go through these types of challenges in our professional lives, where we're faced with coming into an organization and told to build an application security program, a lot of times it's like, "Okay, I can hire some pen testers, and I can roll out SAST", right?

Derek: And you go from there. I think there's a lot of information out there. You can look at OWASP, you can look at NIST, and there's a lot of other content out there. I don't think as far as I've understood or seen one source of here's how you build a program.

Harshil: Yeah, I definitely remember this is more than a decade ago when I was trying to build my second AppSec program, learning from, I didn't want to repeat a lot of the mistakes from the first one, so I went looking for books, and the one I referred to was Gary McGraw's "Software Security: Building Security In", phenomenal book. I'm sure it's still relevant. Lot of concepts related to BSIMM, if you're familiar with that framework, but yes, I 100% agree. A lot of people starting in this domain, there's got to be a simple, easy way to just navigate through this landscape, because it's not just about what makes it fascinating, it's not just about technology. A lot of it is about, has to do with values, with culture, how you interact with other people. processes, all of that stuff combined together is what makes cybersecurity. And there's a lot that could go wrong, right? So you want to avoid those mistakes and learn from a book that lays out the simple foundations and navigates you to a direction that's super useful.

Derek: Yeah, I think you kind of hit the nail on the head there. With our particular type of roles in application security, you do have to rely on your relationships with the development teams and the engineering teams because it's not as simple as just standing up some tools and throwing reports at people. It's not that easy. And there's a lot of negotiation, there's a lot of partnership, there's a lot of conversations that need to be had between your partners in engineering, a. I think the relationships are an important part of that you just don't see as much of that in other spaces within security, where you have to really have a tight coupling with the engineering teams.

Harshil: Right, right. If you were to highlight a few mistakes that people doing this for the first time make in the world of software security, can you think of any?

Derek: Yeah, I always try to bring everything back to risk and I think one of the easy kind of gut reactions is that we have to do things XYZ because that's what everybody else is doing. That's often not the case with application security. You need to take a look at what your organization looks like, what their risks are and what their structure is and what's going to work and what's not going to work, and then come up with that prescription that's going to solve your problems. And you could go to another organization that is the same size, the same industry, building very similar products, and build a completely different AppSec program. The reason for that is, as we both kind of stated, is the culture. Each culture is going to be different in that organization. They're going to be more open to certain parts of application security and less open to others.

Derek: So as an example, one sign of a fairly mature application security program is something like a Security Champions team. And you may not be able to get that off the ground in every organization because it does require buy in from engineering. It requires participation from the people that are in engineering. A lot of times people are volunteered to be a champion and that doesn't always work. And so you can't always go from one organization in the same industry, same size, similar products, and say, "First thing we're going to do is build a Security Champions team" and may work in company A and not work in company B. And so I think saying that things like if you leverage something like BSIMM to look and see what your peers are doing and you say, "well, our peers are doing XYZ and that's what we should do", is often a misstep that many people take.

Harshil: Right, right. So how do you get to that level of understanding what's going to work in the culture or what's not? How do you start let's say you just joined a company, you're leading apps like team building things from scratch. How do you navigate your way around it?

Derek: The first thing that I've always done coming into an organization is start talking to your peers in engineering. I actually touch on this in the Application Security Program Handbook about how to do that, how to find out what are the concerns. Because again, you may come into an organization and speak to your leadership in security, your CISO, and your peers, and they say, "Here's the biggest problem we have, and it's X". And then you go talk to your engineering counterparts and you ask them "what's your biggest security concern?", and they're going to tell you it's Y or Z or whatever they're going to say. It's this other problem that the security organization either isn't even thinking about or not even considering. And you know, that doesn't mean that there's a side to be taken there, but having that information and understanding what the different priorities and what the different concerns are of not just the security organization but also the engineering organization helps you understand what the risk is and what really the priorities are of everybody that you're going to be working with and need to partner with. Because if you go to engineering and say, "Well, security thinks that this is the highest priority and therefore we need to go do that" and engineering saying, "Well, we have this open window over here that everyone keeps climbing through and stealing our data, that's our biggest problem". Again, there's a marrying of the two. At the end of the day, the security organization and the application security team are there to reduce risk and really drive results around security and doing so requires information and it requires information from security and engineering.

Harshil: Right, right. Yeah, and I think one of the outcomes from these discussions could also be understanding of the appetite of these engineering teams to actually do anything about them. Like, they might recognize the risk, but they might be so short staffed, so much under the water that they might not be able to do anything about it in that risk acceptances or just an understanding of what the risk appetite is for that team or for the organization should help you get a better idea.

Derek: Yeah, absolutely.

Harshil: You've talked about several of these topics in your videos in the book as well. For example, I was just briefly looking at things like your thoughts on shift left, shift right, some of those topics. Can you elaborate in the context of when you're building a new program, where should you start? Should you start on the left, should you start more on the right? Or how do you even make that decision?

Derek: Yeah, and again, this depends on the information that you have. If you're coming into an organization with a very robust security organization where you have a lot of runtime protection or you have a lot of the detection and protection tools in the network and host level, then you might have more leeway on the shift right. In other words, you may not have to put as much focus on the shift right because you have compensating controls that are already there to be able to try to protect an application in runtime. Just to kind of level set there, when we look at that development lifecycle, shifting right means you're closer to production, whereas shifting left means you're closer to the actual development of the code. We're shifting right, we're putting different protection tools or detection tools in that production environment specific to the application. Those, again, if you have a more robust security program generally not just application security, but your network security or operational security or cloud security. If that's more robust, then you don't have to focus as much on that. The shifting left is really what we would consider more the blocking and tackling right. It's building in security requirements, it's doing threat modeling, it's training, it's security education, it's the Champions group and it's the partnership with the engineering teams. And to me those aren't quick, those aren't things that just an hour meeting is going to solve all those problems or doing a configuration of a tool is going to solve all those problems. Those are really where you're building that culture of security, where you're integrating processes and people as opposed tools. You have a much longer runway on those things where you could a Champions Program to get it up and running and get it humming the way you want it. It may take you a year, two years, three years to actually get it to where you want it to be. Threat modeling is a process that takes a lot of time and takes people to do. Being able to threat model like the entire architecture of an organization, that's a multi year type of effort. And so these things are things that, in my opinion, you do want to start early because the shifting right part of that where standing up a tool, a WAF web application firewall or runtime application security protection like Rasp. Or API protection or container image scanning or runtime protection on containers. Those things are more purchase, stand up and operate that you can do quicker than you can do those other types of activities. Now again, every organization is different sometimes. We all know those of us that have integrated tools in organizations, we know that it's not here's your software, go install and it's done. It's usually painful and long as well, but it's easier to manage, I think.

Harshil: Yeah, for sure. And getting engineers to integrate things with security software and get it deployed into production, it's not easy but yeah, I 100% understand exactly what you're saying, which is the runtime thing can be solved with technology as compared to shifting left is more of a cultural change process change could take much longer to get to success. You can deploy tools all you want and shift left, but if there's no process or culture associated with doing anything about it, then those tools will continue to produce noise. Which brings me to the topic of AppSed teams these days deploying too many tools and a lot of them ending up being shelf fair or even if they're used, they're only used to generate more noise. One of the reasons that is actually one of the indicators that I've seen is as dev teams and development teams are getting more self-sufficient, self-service, they have the flexibility to choose their own stack and deploy their own infrastructure and their stacks into the production environments. Most companies end up with a highly fragmented technology ecosystem. And to keep up with that, security teams end up deploying many many tools. Not just SEAs and SAST, but also secret scanners, container scanners, DAST, Bug Bounty, pen testing, some open source tools for different frameworks, all kinds of different things. And a very small AppSec team, a handful of people in the team end up with way too many tools, each of them generating too much noise and an island of data in itself. Have you seen any light at the end of this tunnel, of this overwhelming data?

Derek: You know, I think it does take a little bit of self editing in application security, where we shouldn't be any different than engineering, in the sense that tools that we're using, are they really relevant? Are they really useful? We should be asking ourselves those questions frequently. And I often have said to some of the vendors that we work with that, look, I can do application security 100 different ways and it doesn't have to include your tool. It can include two of the tools we're running, it can include five of the tools we're running, it can include none of the tools we're running. I think it comes back down to what are you really trying to protect? More is not better. And if the risk tolerance of the organization is high and warrants the requirement to have a lot of different tools at every single corner of the SDLC, well, that's one thing. If the risk of the organization is low and maybe a SAST tool and runtime protection is enough. And so I think it really comes down to, we kind of not just in security, but I think in technology in general, we tend to think that buying tools, integrating them, that's the path, right? Because it's easy to show, it's easy to put on a slide to say, "Here's all the things we integrated, here's where we're red, green, yellow, and here's the coverage percentage" and things like that, which is great. I think the question we have to ask ourselves really is are we getting value out of those tools? That's something that I've been challenging my team with as well, is just we have to ask ourselves that question, are the tools we're using really valuable? If they're not, then we need to cut them loose. Because it's not just more work on us, it's more work on the engineering teams too. And are we really moving the needle? Are we really becoming more secure by running ten tools as opposed to eight? I think it's just general self editing that we have to do and periodically check in to make sure that we're doing the right thing.

Harshil: Yeah, that's a very pragmatic way of looking at it, right? Because at the end of the day, the objective for most security teams is to mitigate the risk or manage the risk. If you just do the basic things, which is running the tools, then yes, you're getting visibility of the risk. But are you taking the next step? Which is more important? Which is are you actually mitigating that risk or managing that risk in an effective way? If not, then there's not a significant value add by running all these things and finding problems because nobody's actually fixing it.

Derek: Yeah, nothing's worse than doing some vulnerability management and getting if you're looking at a certain product line, you see the vulnerabilities come down and everyone's like, great, we're doing great, we're moving in the right direction, vulnerabilities are coming down. You integrate a new tool and suddenly the vulnerabilities double and everyone's like, what happened? Nothing's more disheartening than doing that.

Harshil: You're collaborating with different product teams, what are the things that you talk to them about? Are those metrics or risk driven conversations or is it something else? What do they need to know? If I'm a dev leader, what do I need to know from you?

Derek: It's a mix of both. I think generally we try to talk more about the bigger picture risk. We talk about what's the future state. I mean that's one of the things I'm always interested in is what is our future state? Because kind of tying back to the previous question about more tools and scanning and stuff, I think we also don't want to pull applications into the application security program that are going to be end of life next year, right? There's also a bit of housekeeping that needs to be done on the engineering side or the product line side to make sure that, hey, are we really securing the right stuff? Because if we're using resources and licenses and time and effort to provide an application security program to an application that's not going to be around for very long, that's wasted effort. I'm talking to the development and engineering leaders, it's really about what's the bigger picture risk? Where are we going, what are some of the new technologies that are coming up and how can we be ahead of that? What are some of the new languages and technologies that they're using so that we know within application security? Do we have the coverage that we need there? Do we need to start getting engaged from a threat modeling and risk assessment perspective? The vulnerability management aspects, the reports and the metrics, those things to me can be sent in an email maybe. If there are specific topics that we need to cover related to those things that are found in those metrics, then we'll talk about that. Something like that is something that I think can be looked at a different time. I prefer having more conversations as opposed to looking over specific vulnerabilities.

Harshil: Right, right. So making it a more strategic, risk driven conversation vulnerabilities is one aspect of that, but not the entirety of the conversation. How do you collect that type of information? I'm guessing there are many many applications, many many dev teams that are also changing at a reasonable frequency. The attack surface is changing, their risk profile is changing. How do you track and record that?

Derek: It's tough. We do leverage our tools as much as possible to try to understand at least what it is that we have. You can only protect what you know. If you don't know about it, you can't protect it. That's where that conversation and we're getting in front of product leaders as well as the engineering leaders to know, hey, what's coming online, what's upcoming that we need to be aware of so that we can start integrating that application security program. There is not really that I'm aware of a way of detecting that an application is on the roadmap automatically. I think you have to really work with your product leaders to understand like, hey, what's upcoming so that we know what we need to do. Now of course, you can detect when somebody stands up an application in your data center or in the cloud that you can find out by then it's too late. In order to get ahead of that from an application security perspective, you need to be in front of the product owners and product leaders.

Harshil: Right. One of the ways that I've seen, and I was just talking to somebody else on another podcast, was that if engineering has a structured process of planning work, right? If at the beginning of the quarter, if they are projecting that we're going to build these features or these applications and that gets recorded in some system of record, whether it's a Jira ticket or ServiceNow ticket or whatever it is, then you can potentially watch out for those tickets and trigger actions based on that. That only works if engineering has that process, has that much way of defining and declaring work.

Derek: Yeah. There are other opportunities that I know that we can leverage. That's working with the enterprise architecture teams because they're getting integrated early on to make architectural decisions. If you're capable or able to be plugged into that level, then that's a great place to be as well. Because not only are you there to see what's upcoming, but you're also participating in that review of that architecture and can make security decisions at that time.

Harshil: Right, right. Okay, so tell me a little bit about Shift Love strategies in your experience. There's a lot of things that can be done in Shift Left, and it's also a big, broad terminology. How should someone start with that initiative? What should be the first few things that they do?

Derek: So I think, again, it depends, I think, on the organization that you're in, but the basic foundation of shifting left is understanding how you track vulnerabilities. I think that's honestly where you then need to start. Because if you start layering in multiple tools. Let's say you start integrating a SAST tool and an SCA tool, software composition, static analysis, dynamic analysis and you integrate those tools and you have nowhere to put those vulnerabilities or no way to triage those vulnerabilities or no way to get in contact with the engineering team to say, hey, here's how you fix it, then it's pointless. So I think the first thing you need to do is understand what's the defect, tracking, and what the defect life cycle look like for development teams so that you can get plugged into that. It's about where are we going to get the most bang for the buck? If you're starting from scratch, a SAST tool is probably not, I may not win a lot of fans for this or I may get some pushback from others, but in my opinion, a SAST tool is not where to start. You want to look at something like a DAST tool, a dynamic scanner, because you want to see for the most part what is exploitable, because you want to catch those first. So a SAST tool and then an SDA tool, software composition, so you can see where your third party library issues are. Those two to me are the two starting points once you have the understanding of what the vulnerability management lifecycle looks like because that'll give you a good indication of like, hey, here's our exploitable for the most part. I mean, you're not going to get everything with a Das tool and not everything is going to be a true positive, but you're going to see what the surface vulnerabilities are with a DAST tool and then with the libraries, you're going to get some good hygiene information around the libraries that you're using that might be insecure. I think those are a good starting point. Then you start looking at bringing in a SAST tool, threat modeling, and kind of turning the screws on shipping left, building a champions program, building up an education program and so forth.

Harshil: Yeah, and that's a good step by step approach because then as I think about what type of skills you would need to do the first steps versus the threat modeling and security champions all that, it's increasingly more strategic skills, increasingly more experienced people that need, who can collaborate and partner with other senior leaders within the organization. I mean, to be a good threat modeler, you have to understand a lot of different things and not just security, more in the architecture world, right? It's not something that a very junior new person can do, I mean, a little bit of an experience. That's a great way to structure step by step maturity of your AppSec program.

Derek: Yes, absolutely.

Harshil: A lot of the conversations that I've been a part of also trigger these thoughts around like when do you actually get involved with dev teams, especially dev teams that are fairly agile. It doesn't have to mean that they release every single day, but if they're fairly agile, they are also planning and delivering their work quickly. When you have a Security Champions program or threat modeling or some sort of interaction that's needed at a certain phase, pre-deployment of the work that dev teams are doing, how do you watch out for those signals that now it is time to reach out to this team or this individual? Do you have any ideas on how you can structure those checkpoints?

Derek: Yeah, I wish it was easy and I tell my boss often that this job is tough and all of us that are in AppSec know that this job is tough because there isn't a light that goes off in the scrum room or on your collaboration tool that says, hey, this team needs you now. It often requires being plugged into engineering and knowing what's going on in terms of releases and knowing where the product is heading and where the features are coming in. My preference is always to be as early as possible in that lifecycle. As soon as we're gathering requirements, as soon as we're building the use cases and the user stories and we know what the customer actually wants from a feature perspective, that is really when we want to be engaged. That looks different in every organization as to when and how to plug into that particular workflow. But it does require just basically, I know this isn't going to be the best answer, but it's going to be ear to the ground, I guess a lot of us are virtual or hybrid at this point, but it's walking the halls, whether it's physical or virtual, to really just be able to understand where the organization is going and what's being built.

Harshil: Right, right. Yeah, that makes sense. I was talking to somebody else who would trigger questionnaires at a certain point when you know that engineering is building a new feature, whether it's a Jira web hook or something like that from a tactical implementation perspective, but trigger questions at a certain point that influences the risk of that particular application. You ask certain questions that drive the risk of that application or the product, and then that triggers automations of scans or tests or threat model activity. So an end to end platform, obviously there's a lot of unknowns in terms of if they respond to certain things in a questionnaire, but then a week later the whole architecture changes.

Derek: It's changed. Right.

Harshil: You don't track that, so you're going to have missed visibility into that but at least it's better than nothing.

Derek: Yeah, and I've seen a lot of cases where a simple intake form, right? And whether it's a security intake form or whether it's the business or product intake form, where, “Hey, we got a new feature coming in, here are the things that we need to do” and just basically putting a have you had security review this checkbox on that form is also helpful because if you can get in front of that activity, then you're getting into that early stages. Additionally, some organizations will have some level of, I don't want to use the word “gate”, but there may be some level of gating where you can't move to production unless you've had a security review. If that process exists and is there, then there's some capability for security to get integrated there.

Harshil: Right, right. Awesome. So do you cover these topics in the book that you’ve written?

Derek: I certainly do.

Harshil: Fantastic. That's a great way. Can you say the name of the book again? Where can users look that book up? Where can they buy it?

Derek: Sure. It's called the “Application Security Program Handbook”. You can find it on Manning.com or you can find it on Amazon. You can also reach out to me on LinkedIn. I'd be happy to help direct from there. The children's book is called “Alicia Connected”, and you can get that on Amazon as well.

Harshil: Fantastic. Derek, it was such a pleasure having you on this podcast. Thank you so much for your time.

Derek: Yeah, I appreciate it. Thank you very much.