Browse Classifications
- All Resources
- Strategic Content
- Technical Content
- Ahead of the Breach Podcast Content
- Partner Program Content
Sean Finley, Director of Application & Product Security at Eptura, shares invaluable insights on building effective application security programs. Learn why flooding backlogs with vulnerabilities isn't the answer and discover how to create security processes that truly serve business goals while managing risk effectively.
Every month, Casey Cammilleri interviews an expert leading the charge on empowering security experts and practitioners with the knowledge and insights needed to excel in the future of cybersecurity.
We recently spoke with Sean Finley, Director of Application & Product Security at Eptura. Here are the top takeaways from the interview.
“It's one thing to have 100% of the findings, but if they can only work on 1% at a time, am I benefiting them by just throwing it over the fence, all 100% at one time, or is it better for me to have a conversation with them about the risk that's presented, that I do the analysis on the criticality of the findings, the exploitability of the findings, the reachability of the findings, and helping the business to understand what all of that means to them and where we should focus our time?
“Whether it's in the backlog or not, sometimes that's a perception issue. Do you build bridges by filling up a bug tracker with thousands of tickets? Or do you build bridges by saying, ‘I understand what you're doing right now, I understand where you're at. These are the things that I think are going to move the needle for us in the short term, and in the long term, I still have work for you to do, but we're going to focus on this.’
“And I think that that speaks a lot to how software is built. Building out new features, building out products. It's not everything at once and everybody worried about the entire product at one time. It's about getting the next feature out. It's about winning those battles. And that's kind of the perspective I take, is I like to kind of take what I've learned in building software, kind of apply that to how I deal with vulnerability management.”
Actionable Takeaway: Align vulnerability management with your development team's actual capacity and workflow patterns. Instead of overwhelming teams with every finding, analyze criticality, exploitability, and reachability to create focused, manageable security priorities that match their sprint cycles and resources. This strategic approach builds trust and ensures steady progress toward security goals.
“I'm always trying to figure out who the business people are that are impacting those products, those applications. Usually they're the ones who are grabbing engineering time for features and a lot of times setting the sprint schedules and what are they doing when.
“So for me, I need to be in within the room with them, so to speak, getting in their ear and letting them know what risks are in their products, giving them the lay of the land, what impacts that has to the business and then hopefully making the case that they see the value or building relationships that I can beg and borrow from their sprint times to do some things.
“But I really do think that getting the business involved and becoming a stakeholder in it and owning the fact that a functional bug and a security bug are equally as important to them. It's not always, features come first. Sometimes you gotta deal with the stuff that isn't something you can put on a marketing sheet. You gotta deal with the stuff that could cause a breach and the kind of press that you don't want to have to explain in a sales call.”
Actionable Takeaway: Proactively engage with business stakeholders who control development resources and sprint planning. Build relationships that position security as a critical business concern equal to features, demonstrating how security vulnerabilities directly impact revenue, customer trust, and sales conversations. This approach helps secure necessary resources for security improvements.
“If they want a vuln management program because they need to check a box that says they have a vuln management program that's very different than if they, if you have stakeholders who want a vulnerability management program because they actually want to get rid of vulnerabilities. So understanding your space, I think, is very important because I think that changes what you can leverage.
“But, assuming that we're all working for organizations who do want to get rid of vulnerabilities, I think it's about understanding the risk tolerance of the business. I like a risk-based approach to dealing with vulnerabilities. I like to look at as much contextualization as I can, taking in as much information as I can, the intel on the vulnerabilities themselves and making sure that we're focused on things that are going to be impacting revenue-generating streams or business-critical systems.
“We need to be looking at those things, talking about, let's say open source issues. Are we looking at things that have mature exploits or just theoretical academic exploits and, where do we spend our time?”
Actionable Takeaway: Move beyond checkbox compliance by building vulnerability management programs that reflect your organization's unique context and risk tolerance. Focus on gathering comprehensive intelligence about vulnerabilities, including exploit maturity and potential business impact, to prioritize fixes that protect critical revenue streams and core systems effectively.
Continuous Human & Automated Security
Continuously monitor your attack surface with advanced change detection. Upon change, testers and systems perform security testing. You are alerted and assisted in remediation efforts all contained in a single security application, the Sprocket Platform.