Starting Strong: Taming AppSec Chaos from Day One

‍

Introduction

The moment you accept an offer for a new role as an AppSec leader, the challenges start. Whether you join a large enterprise or a small startup—and whether your title calls you a Team Lead, a Director, a VP, or something else—you start on Day 1 with a limited understanding of the environment you’re getting yourself into.

To create this guide, we interviewed experienced AppSec leaders on how they see the challenges and opportunities offered by a brand-new role in the first 90 days on the job. 

Every one of our interviewees agreed: the first 90 days in an AppSec leadership role can make or break your long-term impact. Jump in too fast, and you risk fighting fires reactively instead of setting strategic priorities. Spend too much time observing without action, and security debt piles up while developers stick to old habits. The key is striking the right balance—building relationships, assessing gaps, and securing quick wins—so that by day 90, you're not just reacting to risks, but driving real, iterative security improvements.

Understanding Your Domain: Foundations of Security Success

Discovery Phase (Days 1-30): Understanding Your Team and the Business Landscape

In your first month, multiple security leaders said to ignore any impulse to dive right in to security architecture, tools, and challenges. Instead, they encourage a broader approach based on understanding business fundamentals.

Start Relationships Right: For this phase to be most successful, you’ll need to spend time meeting and beginning to build relationships with your counterparts in engineering, QA, DevOps, IT, and other security teams—as well as teams further afield, like customer success and marketing.

“Start by discovering as much as you can about the business—don’t ask so many AppSec questions,” said Naor Penso, VP of Product Security at FICO. “A good AppSec leader has a deep understanding of the business and how they deliver value to their customers.”

No Rabbit Holes: Teja Myneedu, Director of Security at Navan and formerly Director of Product Security at Splunk, puts the brakes on before delving too deep into security. “As a hands-on security engineer, I gravitate toward looking at source code and infrastructure, architecture diagrams, things like that,” he said. “I have to consciously stop myself before I dive deeper and say, ‘let’s not go down the rabbit hole, let me look at the big picture.’” 

According to Myneedu, “It’s really crucial to understand breadth: overall, what does the company do? What do its products do? What kind of data do we have? That’s where I’d spend my first weeks, which will help me get clarity on where I need to dive deeper.”

Look Before You Leap: Even if you’re eager to roll out process changes, the first 30 days isn’t the right time. “Successful security strategies start with empathy, and that comes from developing relationships,” said Sumeet Jain, VP of Product Security at BeyondTrust. “Learn the lay of the land, how many customers, how many products. ”Get the relationship angle covered first, before showing people the problems and changing anything in the process.”

Observe Without Changing: One big security-related task for your first 30 days can be to learn what security tooling is being used across the organization—and make a note of any duplicate tools, where different teams use products that solve the same problem. You should also note where there are manual processes and handoffs that seem broken at any point in the SDLC, from design to deployment. You don’t need to change anything yet. Just write it down for your own reference.

Quick Win For Day 30: Model the Business

Making initial connections across departments and domains can help you map out a high-level model—either a mental or digital one—of the organization itself. According to Naor Penso, that model can be more valuable to more parts of the business than you think.

“The thing that distinguishes AppSec and product security leaders from everyone else is that they’re the only ones, along with their teams, who have a view of every part of the SDLC from the design phase to when clients are using it,” he said. “IT, engineering, architecture, account management, post-sales, professional services—everyone is siloed. Security people are the only ones who get to see the whole story.”

Because of that visibility, Penso said, “As an AppSec leader, you can create huge business value by creating an outline of how the business works. Here’s this process with many subprocesses, here’s how these teams fit together, here’s the handovers—and this one or that one is broken.”

By sharing this bird’s eye view of the business with your counterparts in other departments, you can start off relationships right, using your unique position in the organization to help others understand it better.

The Bottom Line: What Matters is the Bottom Line

While relationship building isn’t every AppSec leader’s favorite part of the job, skipping out on building this initial understanding can be a critical mistake. Change too much without enough business context, and you’ll find you’re costing the business more than you’re saving.

Penso said the focus on fundamentals and relationship building is a simple matter of business priorities: “Ultimately, the company’s job is to deliver software to clients and bring money in. If you don’t understand who the clients are and what you’re selling, you can’t meet those needs and solve for client demands.”

Checklist For Discovery Phase (Days 1-30):

• Meet with counterparts in engineering, DevOps, QA, customer success, sales, and marketing.

• Discover organizational structure and processes

• Learn how your new organization’s products are built and sold

• Build a mental or digital model of the organization’s SDLC

• Note any broken handoffs or processes in your SDLC

• Identify any specific security issues that have previously had a business impact

• Assess the state of automation—what’s manual? What slows people down?

• Identify duplication in security tooling across teams and products

Closing Gaps and Focusing on Fundamentals

Stabilization Phase (Days 31-60): Implementing Core Security Practices

As you transition into the next phase of your role, your focus should shift from understanding the business landscape to actively addressing security practices. This is your opportunity to solidify the foundation of your AppSec program, ensuring that key security processes are functioning well and aligned with the broader business objectives.

Review What You’ve Got: During your first month, you’ve likely become familiar with the team and the security tools in use. Now is the time to dig deeper and assess the security practices currently in place across critical areas: vulnerability management, disclosure processes, security hygiene in build pipelines, and open-source security practices.

“Understanding the current state of these practices is essential. There’s often a mix of good, bad, and overlooked processes, and your job is to get a clear picture,” said Penso, who emphasizes the need for a deep dive rather than jumping into complex security initiatives right away.

Establish a Baseline: As you review existing practices, it’s crucial to establish what "good security hygiene" looks like within your organization. This means creating clear definitions for what constitutes acceptable levels of security in build pipelines, vulnerability management, and handling open-source dependencies. Without this baseline, it’s difficult to prioritize and implement improvements. "You have to set a clear bar for what 'good' means, especially when dealing with disparate teams," Myneedu said.

Fix Glaring Issues: Before diving into more complex security strategies like threat modeling or penetration testing, focus on fixing glaring issues that may have been neglected in the past. This may include ensuring secrets management, improving vulnerability scanning processes, or streamlining incident response workflows. These basic practices are the foundation for your team's future success, and neglecting them will make any advanced tactics ineffective—don’t start building castles in the sky until the ground is solid. 

Meaningful Metrics: One of the most valuable actions you can take in the 30-60-day window: introducing security metrics that are more than just reports. As Myneedu put it, "Security metrics should drive decision-making, not just sit on a dashboard for reporting." These metrics should be tied to business outcomes, risk mitigation, and operational efficiency. Focus on measurable actions that demonstrate progress in areas like vulnerability remediation time, incident response effectiveness, or the adoption of secure coding practices. These numbers should become key drivers in your decision-making process.

Get Disclosure Right: One of the most critical responsibilities in the Stabilization Phase is to begin building a scalable vulnerability management and disclosure process. This process will form the backbone of how vulnerabilities are tracked, remediated, and disclosed, both internally and externally. If you inherit a fragmented or outdated process, now is the time to restructure it for efficiency and scalability. Automate as much of this process as possible, and ensure that it's aligned with your broader goals, including improving the speed of remediation and enabling your teams to act swiftly when critical vulnerabilities are discovered in your products. Hopefully, it will be a long time before you have to use this process—but at least you’ll know it’s there.

By the end of the Stabilization Phase, you should have a solid foundation in place, with key security processes functioning smoothly, the right metrics guiding decisions, and clear steps for automation and scalability mapped out. The emphasis in these first 30 to 60 days is all about refining the basics, getting the processes right, and setting yourself up for long-term success.

Quick Win for Day 60: Eliminate a Vulnerability Class

According to Sumeet Jain, a big way to gain credibility quickly in your organization can be to tackle one specific type of risk first, across the environment. “Find out what you’re most susceptible to and zero in on solving one of those risks fully—with just one type of vulnerability you want to eliminate,” he said. “Since any type of vulnerability can be triggered in several ways, do it end-to-end. Eliminate one type of ‘low-hanging fruit’ vulnerability in production, in the code and design. Sometimes that’s just secrets detection, lots of places have secrets in plain text. Fixing just one thing well gives you more credibility than focusing just on overall MTTR or remediation velocity.”

Jain said one of the biggest advantages of working this way can be getting executive buy-in. “CISOs almost never come from an AppSec background,” he explained. “Data isn’t straightforward in AppSec, and the rate of change is high, because the code changes literally every day. But when you think about vulnerability classes, we can train developers, we can make change at a broader cultural level.”

Checklist for Stabilization Phase (Days 31-60)

• Review existing security practices in: (i) Vulnerability management; (ii) Disclosure; (iii) Security hygiene in build pipelines; and (iv) Open-source security practices
  
• Establish a clear baseline: define what "good security hygiene" looks like
• Fix most glaring issues and plug urgent gaps

• Introduce security metrics that drive decision-making, not just report activity

• Automate first—eliminate inefficiencies before they scale

• Build a scalable vulnerability management and disclosure process

Ready, Set, Scale: Strengthening the Core

Optimization Phase (Days 61-90): Aligning Security Strategy with Business Goals

As you move into the Optimization Phase (Days 61-90), your focus should shift from initial stabilization to driving greater operational efficiency, aligning security efforts with business priorities, and automating processes for long-term scalability. This phase is crucial for showing executives your leadership style and driving the success of your future strategic initiatives.

Detection & Visibility: Effective, scalable security practices start with being able to detect vulnerabilities in a scalable way—which means standardization matters a lot. Duplication of tools across teams creates inefficiencies and friction, as well as causing blind spots for both developer and security teams. By improving visibility into vulnerabilities across multiple products and introducing automation, you can gain a clear picture of the security landscape while also accelerating detection processes.

“We standardized our tools to avoid duplication,” said Sumeet Jain, a seasoned AppSec leader. “Once you have the right tooling in place, you can start to automate detection. The key here is visibility across the board—only then can you focus on remediation.” Automation in detection capabilities isn’t just about efficiency; it's about making security scalable. As your product suite and infrastructure grow, your security strategy must grow with it, which requires having automated systems to detect vulnerabilities faster and more accurately.

Operational Efficiency: To drive true operational efficiency, you need to streamline processes like ticketing and remediation workflows. Defining Service Level Agreements (SLAs) for security fixes that align with business priorities ensures that security efforts do not impede product delivery, but instead complement the broader business goals.

Alongside remediation workflows, the optimization phase involves creating a scalable process for handling vendor security, responding to customer security inquiries, and addressing Requests for Proposals (RFPs). These processes must be robust and repeatable, supporting the company’s ability to handle security at scale while maintaining credibility with customers and vendors.

Automate for Scale: Every AppSec leader we interviewed emphasized the importance of automation in scaling security operations. Manual processes are slow, error-prone, and difficult to maintain as your company expands. In this phase, the focus should be on automating wherever possible—whether it’s in vulnerability management, incident response, or code scanning.

Sumeet Jain put it succinctly: "It’s non-negotiable to do automation first. Devs won’t go out of their work environment, and adding any new manual process will not scale. You don’t go from manual, to semi-automated, to automated. That may seem like it will work, but it just does not scale."

Shifting from “Find More” to “Fix More”: In the early stages of an AppSec leader's tenure, there may be an instinct to focus on finding more vulnerabilities—identifying gaps, scanning codebases, and increasing the volume of findings. However, as Naor Penso pointed out, "Security teams don’t fix vulnerabilities—developers do. You can’t just keep pushing new findings without a focus on remediation.”

The true value of security lies in fixing the vulnerabilities that matter most. You should shift your approach from “Find More” to “Fix More.” This means prioritizing high-impact vulnerabilities, streamlining the remediation process, and ensuring that your findings are actionable.

Right-Size Your Toolbox: Adding more security tools doesn't necessarily improve security if you don't focus on the core issue—remediation. Instead of overwhelming developers with endless vulnerability lists, prioritize issues that pose the greatest risk to the business. "Provide curated vulnerability lists that take business context into account, not endless findings. Developers need clear guidance on what matters most,” said Myneedu.

Additionally, improving developer security education and enabling Dev teams with security champions will help embed a security-first mindset within engineering teams. Shifting security responsibility to the developers themselves, rather than treating security as a siloed function, ensures that security is not seen as an obstacle but as an enabler of business success.

Build Credibility with Devs: Security is often perceived as an obstacle or a compliance burden, but to align with the business, you must go beyond the “checklist” mentality and speak the language of developers. Show that security isn’t just about saying "no" but about enabling innovation. Providing curated vulnerability lists and clear, actionable remediation instructions will go a long way in building trust with engineering teams.

Balancing urgency is key here. As Sumeet Jain said, “Security teams need to know when to put their foot down and block a release versus when to find a middle ground.” Understanding when to escalate security issues and when to allow flexibility is crucial for maintaining a balance between security needs and business goals.

By working closely with engineering teams, you can help create a shared responsibility model where developers understand the security implications of their code and take ownership of security practices. This collaboration fosters a security culture that supports business objectives while reducing friction between security and development teams.

This phase marks a pivotal point where your AppSec program transitions from stabilization to optimization. With an increased focus on automation, operational efficiency, and fostering collaboration between security and development teams, you’ll be well-positioned to scale your security efforts in alignment with the company’s overall business strategy. By automating for scale, prioritizing remediation over detection, and building credibility with engineering, you’ll be able to ensure that security doesn't just keep up with the company’s growth—it drives it.

Quick Win for Day 90: AppSec “State of the Union”

By Day 90, you should be prepared to deliver an AppSec “State of the Union”—a clear, concise report on where the security program stands and where it’s headed. This presentation to leadership, including cross-functional stakeholders, should highlight your accomplishments so far, key risks, and the steps needed to mature the program further. Sumeet Jain emphasized the importance of framing this discussion around business impact: “Security is in the service of the business, not the other way around.”

As you prepare for this moment, focus on presenting clear metrics that showcase the progress made in foundational security practices, such as vulnerability management, remediation, and automation.. Teja Myneedu said it’s also crucial to share actionable next steps: “The leadership needs to see not just what has been done, but what comes next—how you're solving current challenges and scaling security for the future.” The AppSec State of the Union report is your opportunity to align your security strategy with business goals, building momentum for the next phase of your AppSec leadership.

Checklist For Optimization Phase (Days 61-90):

• Standardize security tooling across teams to avoid duplication

• Define Service Level Agreements (SLAs) for security fixes aligned with business priorities

• Develop scalable processes for handling vendor security, customer inquiries, and RFP responses

• Identify manual processes that need to be automated for greater scalability

• Ensure automation is integrated into the developer environment to prevent bottlenecks

• Prioritize fixing high-impact vulnerabilities over finding more vulnerabilities

• Curate vulnerability lists to highlight the most critical issues for remediation

• Compile key security metrics that show progress in vulnerability management, automation, and remediation

• Present your “AppSec State of the Union” to executives and security teams

AppSec Leadership Pitfalls: Common Mistakes For Year 1 (and How to Avoid Them)

Mistake #1: Acting as a Security Cop Instead of a Business Enabler

One of the quickest ways to derail your role as an AppSec leader is adopting a “security cop” mentality. When you focus solely on enforcing rules without considering the bigger picture, you risk creating friction with engineering teams and missing out on opportunities to align security with business needs. Naor Penso echoed this, saying, “Security has to enable the business. You can’t simply say ‘no’ or ‘block’ a release. You have to show that security is making the company stronger, not just protecting it.” AppSec leaders who approach security as a collaborative, enabling role—rather than a restrictive one—are much more likely to build trust with engineering teams and support the overall goals of the business.

Mistake #2: Relying Too Heavily on Manual Processes Instead of Automation-First Approaches

Another big red flag is leaning too heavily on manual processes. Sumeet Jain made it clear that automation should be a top priority for any security leader: “If you’re not already thinking about automation from day one, you’re setting yourself up for failure.” Manual processes may work for a while, but as your security program grows, they’ll quickly become inefficient and prone to error. Automating things like vulnerability scanning, incident response, and code analysis will help you scale your program effectively and avoid burnout from repetitive tasks.

Mistake #3: Focusing on Detection Over Remediation

Detection is important, but it’s all too easy to fall into the trap of just finding vulnerabilities without actually fixing them. Jain also highlighted the importance of shifting the focus from “find more” to “fix more”: “Security teams don’t fix vulnerabilities—developers do. You need to focus on working with developers to prioritize remediation and help them solve real problems, not just add more noise with endless findings.” If your security program focuses only on detection without a clear plan for remediation, you risk creating frustration across the organization, leaving vulnerabilities unresolved and technical debt piling up.

Mistake #4: Ignoring the Developer Experience

Security initiatives can easily become a burden for developers if they’re not thoughtfully integrated into their workflows. Teja Myneedu emphasized that security should empower development teams, not slow them down: “Security shouldn’t be about adding friction or creating blockers. It should be about helping developers build secure applications by integrating security directly into their workflows.” If security is seen as an obstacle, developers won’t engage with it, and the overall security posture will suffer. Make sure developers know the “why” behind security requests, and prioritize the most important vulnerabilities in an easy-to-digest, curated list.

Mistake #5: Introducing Tools Without Integration into Developer Workflows

Closely tied to the previous point is the risk of introducing security tools that aren’t integrated into developer workflows. Tools need to be integrated in ways that don’t disrupt developers. They shouldn’t have to leave their environment to interact with security tools. Automation, integrations, and API-first approaches are key to making tools effective—so if your security tools exist in silos, disconnected from the tools and environments developers are already using, they’ll be ignored or bypassed. To be effective, security tools should blend seamlessly into the developer workflow and make security easier to manage—not harder.

Mistake #6: Buying Unnecessary Tools that Add Complexity

It’s important to be discerning when deciding whether to introduce a new tool. Not every security problem requires a shiny new product. Jain shared a word of caution: “Adding more security tools doesn’t necessarily improve security—it just adds complexity. Before purchasing a new tool, ask yourself if it will actually solve a problem or if it's just adding another layer to manage.” Sometimes, optimizing or better utilizing the tools you already have can be more effective than continually adding new ones to the mix. Streamlining existing processes might solve the problem more efficiently than purchasing additional tools.

The Road Ahead (Day 91…and Beyond): Ensuring Your Long-Term AppSec Impact

As you push past the first 90 days, your focus should start shifting. You've built the foundation—now it's time to start thinking bigger. The goal should no longer be just about "doing security" but about "enabling secure development." It’s all about integrating security into the fabric of how your teams build software. Security shouldn’t be a roadblock, it should be a seamless part of the development process.

To scale security long-term, it's not about just adding headcount every time you face a challenge. The trick is working smarter. Lean into automation, streamline your processes, and make sure you’re not adding complexity for the sake of it. Scaling security doesn’t mean just throwing more people at it; it means making security as efficient and automated as possible. This way, you avoid burnout and unnecessary expansion while still increasing your impact.

Another key area for long-term success is earning credibility—both with developers and leadership. With developers, it’s about showing them that security isn’t just about saying "no," it’s about helping them do their jobs better and making their software more secure. With leadership, it’s about demonstrating that security aligns with business goals, reducing risk, and driving value. You’ll build that trust over time, but being transparent and consistent is the best way to show your team that you’re all in it together.

Finally, instead of continuously chasing vulnerabilities, focus on building a system that prevents security issues from happening in the first place. Think long-term, building processes and a culture that proactively reduces risk. As Teja Myneedu put it, “It’s important to understand that security is not a one-time check—it’s an ongoing process. You build a foundation, and you keep improving it.”

‍