This interview is with Udaya Bhaskar Vemuri, Senior Application Security Analyst.
For Connectively readers, could you introduce yourself—what does a Senior Application Security Analyst do in your world, and where do you focus your time and impact?
I’m a Senior Application Security Analyst, which means I help companies make sure their applications are safe before they are released to customers.
I work closely with software teams to find security problems early, when they are easier and less expensive to fix. I review how an application is designed, check for possible risks, and use security tools to look for weaknesses in the software code, websites, online services, and third-party tools.
My job is not only to find problems; I also help developers understand which issues are serious, which ones may be false alarms, and how to fix them in a practical way. The goal is to improve security without unnecessarily slowing down the development process.
I also help add security checks into the normal software-building process, so problems can be found automatically before an application goes live. More recently, I have been exploring how artificial intelligence can support security reviews, reduce manual work, and help teams identify risks faster while still keeping people involved in the final decisions.
The main impact of my work is helping organizations release safer applications, reduce security risks, and make security easier for development teams to follow.
How did you grow into enterprise AppSec and DevSecOps, and which pivotal experiences most shaped your approach to vulnerabilities, patching, audits, and threat modeling?
I grew into enterprise application security by working closely with software teams and seeing how security decisions affect real applications, customers, and business operations.
Early in my career, I learned that finding a vulnerability is only the first step. The real challenge is understanding how serious it is, whether it can actually be exploited, and how quickly it should be fixed. That experience shaped how I approach vulnerability management today. I focus on the real risk rather than treating every finding the same.
Working with large organizations also taught me the importance of patching and clear ownership. Security issues can remain open when teams are unsure who should fix them or when a change might affect an important system. I learned to work with developers, infrastructure teams, and business owners to prioritize fixes, agree on timelines, and use temporary security measures when an immediate fix is not possible.
Audits gave me another important lesson: good security work must be supported by clear evidence. It is not enough to say that a problem was fixed. Teams should be able to show what was reviewed, what action was taken, who approved it, and how the result was verified.
Threat modeling helped me move from reacting to problems toward preventing them. By reviewing how an application handles users, data, access, and communication before development is complete, I can help teams identify risks much earlier.
These experiences shaped my approach to AppSec and DevSecOps. I try to make security practical, risk-based, and part of the normal development process rather than something added only at the end.
Can you share a real example where a medium-severity vulnerability became your top risk due to exposure or ownership gaps, and how you recognized it before it turned into an incident?
In one case, a security tool reported a medium-severity vulnerability in an internet-facing application. At first, it did not appear to be urgent because the technical rating was only medium.
When I reviewed it more closely, I found that the application was publicly accessible, handled sensitive business information, and did not have a clearly assigned owner responsible for fixing it. I also noticed that the vulnerability had remained open for some time because different teams assumed someone else was handling it.
That combination changed the risk profile. Even though the technical severity was medium, the public exposure, sensitive data, and ownership gap made it one of the highest-priority issues for the organization.
I brought the development, infrastructure, and business teams together, confirmed who owned the application, and helped them create a clear remediation plan. While the permanent fix was being prepared, temporary security measures were added to reduce the exposure. The issue was then tested again to confirm that it was fully resolved.
This experience reinforced an important lesson for me: a vulnerability rating alone does not tell the whole story. Exposure, business impact, and clear ownership can make a medium issue much more serious. By reviewing those factors early, we were able to address the risk before it became an incident.
When triaging across SAST/DAST/SCA/container/cloud findings, which signals do you trust most (e.g., internet exposure, active exploit code, KEV/EPSS, business criticality), and how do you assign ownership quickly?
When I review security findings, I do not rely solely on the severity rating. A “critical” finding is not always the highest risk, and a “medium” finding is not always low risk. I look at the bigger picture before deciding what should be fixed first.
The first things I consider are:
- whether the application is exposed to the internet — a weakness in a public-facing application usually deserves faster attention than the same issue in an internal system
- whether similar vulnerabilities are already being exploited by attackers
- whether it affects sensitive customer or business data
- how important the application is to the organization
Another important factor is whether the security finding is genuine. Automated tools can sometimes report false alarms, so I review the results carefully before asking development teams to spend time fixing them. This helps everyone focus on the issues that present real risk.
Assigning ownership is just as important as identifying the problem. I work with development, infrastructure, cloud, and business teams to determine who is responsible for the application and who can resolve the issue. Clear ownership helps prevent vulnerabilities from remaining open simply because no one knows who should take action.
My goal is to make security decisions based on real business risk instead of technical scores alone. By combining technical findings with business context, exposure, and clear ownership, organizations can fix the most important issues first and reduce the chances of a security incident.
What patching and exception workflow has worked best for you—SLAs by risk, compensating controls, and developer engagement—to cut time-to-remediate without creating ticket churn?
The most successful approach I have seen is treating security as a shared responsibility instead of simply assigning tickets. Before asking a development team to fix an issue, I first confirm that the finding is genuine, understand how much risk it creates, and identify the correct application owner. This helps avoid unnecessary work and prevents teams from spending time on false alarms.
I believe security issues should be addressed within timelines based on their level of risk, especially if they affect applications that are exposed to the internet, handle sensitive data, or support important business operations. Lower-risk issues can often be scheduled as part of normal development work instead of interrupting ongoing projects.
There are also situations where an immediate fix is not possible because of technical limitations or business priorities. In those cases, I work with the teams to put temporary security measures in place, such as restricting access, increasing monitoring, or adding additional protections, until the permanent fix can be completed. Every exception should have a clear reason, an owner, and a review date so it does not remain open indefinitely.
Good communication is just as important as the technical solution. Instead of simply sending a list of vulnerabilities, I explain why an issue matters, what the business impact could be, and how it can be resolved. Developers are much more engaged when they understand the reason behind the request.
In my experience, combining risk-based prioritization, clear ownership, temporary security measures when needed, and regular communication helps organizations reduce the time it takes to resolve security issues while avoiding unnecessary ticket churn.
What is one threat modeling or secure design review practice you embedded into CI/CD that consistently caught issues pre-production, and how did you keep it lightweight so teams embraced it?
One practice that has worked well for me is moving security reviews earlier in the software development process, rather than waiting until an application is almost ready for release. Finding problems early gives development teams more time to fix them when changes are easier and less expensive.
I encourage teams to complete a short security review whenever they introduce a new feature, connect to another system, or handle sensitive information. Rather than asking dozens of technical questions, I focus on a small number of important areas to keep the review practical and easy to complete:
- How users are authenticated
- How sensitive data is protected
- What external services are connected
- What could happen if something goes wrong
I also support development teams by adding automated security checks directly into the normal software-building and release process. These checks can identify common security issues before the application reaches production, allowing developers to receive feedback while they are still actively working on the code.
More recently, I have been exploring how artificial intelligence can assist with secure design reviews by helping identify potential risks, organizing security observations, and reducing repetitive manual work. However, the final decisions are always reviewed by security professionals to ensure accuracy and proper business context.
I believe security succeeds when it fits naturally into the development process rather than slowing it down. By keeping reviews simple, automating routine checks, and providing clear guidance, teams are more willing to adopt secure development practices as part of their everyday work.
When working toward frameworks like NIST CSF, how do you translate audit requirements into everyday developer behaviors, and what evidence have auditors accepted without slowing releases?
Security frameworks such as the NIST Cybersecurity Framework provide useful guidance, but I believe developers should not have to memorize them. My goal is to turn security requirements into simple, everyday steps that naturally fit into the software development process.
Instead of asking teams to complete separate security activities before every release, I encourage them to build security into their normal workflow. This includes reviewing new features for common risks, running automated security checks, documenting important design decisions, and making sure security issues are addressed before software is released.
I have found that auditors are usually looking for clear evidence that security processes are being followed consistently. Helpful examples include records showing that security reviews were completed, automated security scan results, documented approvals for any accepted risks, and records showing that important security findings were resolved or formally reviewed before release. When these records are created as part of the normal development process, teams do not have to spend extra time gathering evidence later.
I also believe communication is important. Developers should understand why a security requirement exists instead of viewing it as another compliance task. When security becomes part of the team’s everyday work, audit preparation becomes much easier because the evidence already exists.
My approach is to make security practical, repeatable, and easy to follow. That helps organizations meet security and audit expectations while allowing development teams to continue delivering software efficiently.
Where has AI genuinely accelerated your AppSec work (for example, summarizing findings, SBOM analysis, or PR reviews), and what human checkpoints kept decisions accountable and safe?
AI has been most valuable in reducing repetitive work, allowing me to spend more time on security decisions that require human judgment. Instead of reading large amounts of technical information manually, I use AI to organize findings, summarize reports, identify common patterns, and highlight areas that deserve closer attention.
AI has also been useful during secure design reviews. It can quickly review application information, point out potential security risks, and suggest questions to discuss with development teams. This helps me prepare for reviews more efficiently while ensuring important areas are not overlooked.
However, I never rely on AI to make final security decisions. AI can misunderstand technical details or miss important business context. Before accepting any recommendation, I verify the findings, review the supporting evidence, consider the application’s business purpose, and discuss significant decisions with the development team when needed.
I believe AI works best as a knowledgeable assistant rather than a replacement for security professionals. It speeds up routine tasks, but people remain responsible for validating results, making risk decisions, and approving the final outcome.
The biggest benefit has been that it gives me more time to focus on complex security reviews, collaborate with development teams, and solve higher-value security challenges instead of spending hours on repetitive manual work.
Which two or three metrics or narratives have best convinced executives that you’re reducing exploitable risk—not just closing tickets—and how do you present them to earn continued investment?
I have found that executives respond best to metrics that show how security reduces business risk instead of simply reporting the number of vulnerabilities that were fixed. A long list of closed tickets does not always mean the organization is more secure.
One of the most useful measures is how quickly high-risk security issues are identified and resolved. I also track whether the most important applications have fewer unresolved high-risk findings over time. Another helpful measure is how many security issues are found early in development instead of after software has already been released, because fixing problems earlier reduces both cost and business disruption.
I also believe that numbers alone are not enough. I like to include short examples that explain how a security improvement reduced risk, prevented a potential incident, or helped development teams release software more safely. Real examples make the impact easier for business leaders to understand.
When presenting results, I avoid technical language whenever possible. Instead, I explain how security work protects customer data, supports reliable business operations, reduces future costs, and lowers the chances of a security incident. That makes it easier for executives to see the value of continued investment.
My goal is to help leaders understand that the success of an application security program is not measured only by how many tickets are closed but by how effectively the organization’s overall risk is reduced while allowing the business to continue moving forward.
Thanks for sharing your knowledge and expertise. Is there anything else you'd like to add?
Application security works best when it is treated as a partnership rather than a final checkpoint. Security teams, developers, business owners, and leaders all share responsibility for reducing risk.
The strongest programs are not the ones that create the most tickets or use the most tools. They are the ones that help teams identify important risks early, make practical decisions, and build safer software without slowing down the business.
As technology and artificial intelligence continue to change how software is developed, security teams must keep learning and adapting. At the same time, human judgment, clear ownership, and accountability should remain at the center of every important security decision.
My focus is to make security practical, understandable, and part of everyday development, so that safer software becomes the normal way of working.