Evolving technologies and the dynamic relationship between security systems and business IT systems require that the teams responsible for them are equally trained and staffed to tackle cybersecurity threats. This interconnected world of systems and teams is driving a skills shortage. Veerbhadra Magdum, CCSP, shares two examples that demonstrate how skills and people are vital to vulnerability management.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
Organizations rely heavily on their IT systems for most of their data processing and operations. All the systems are interconnected and any cybersecurity threat to these systems can compromise sensitive data, or cripple operations through the erosion of public trust. To alleviate these concerns, organizations invest heavily in centralized governance, risk and compliance teams that set up policies used to guard sensitive data and IT operations. Additionally, enterprise information security teams are set up to make sure that policies specific to information security are created and various teams within security are responsible for setting up and maintaining systems required for this purpose.
To illustrate how skills and people are vital to vulnerability management in such an interconnected environment, I’d like to share two scenarios I’ve experienced while reviewing vulnerability scan reports for an application.
The application under review is a three-tiered web application comprising application, web and database components. The application team owns the source code and sensitive customer data; the middleware team owns the web server and uses RHEL Tomcat to serve application source code. Enterprise information security teams own the security systems that scan applications and provide lists of vulnerabilities for the application team to resolve.
Exploitation of a Globally Deployed Platform
Cl0p is a criminal organization known for multilevel extortion techniques and malware distribution. In October 2025, criminals purporting to be from Cl0p claimed that they had exploited a zero-day flaw to breach Oracle E-business suite (EBS) deployments across multiple organizations. That vulnerability is now documented as CVE-2025-61884. At the time, organizations were pushed into a confusing chain of events to understand the impact of the claim.
My organization, which had such an Oracle EBS deployment, wanted first to understand if systems were directly impacted and if any data had been accessed. My organization was also potentially impacted indirectly, via a vendor hosting our data in its Oracle EBS system. Establishing these basic facts required the involvement of and coordination between multiple teams like GRC, cybersecurity, management and Oracle EBS system owners. We needed to classify the impact as direct or indirect and to understand the technicality of the vulnerability, the data impact and the resolution path.
It was an eye-opening event. Here is what I learned about being prepared for such an event in the future:
- A single application vulnerability may require extensive collaboration across multiple teams and also requires that the teams involved have staff with common security skills.
- The combination of a compromised platform used on a global scale and organizations that may be understaffed or have insufficient skills to analyze such a widespread operational impact, could have severe compliance consequences – especially on organizations that may be vulnerable to indirect impact due to multiple third-party vendors.
- The Security team should not be the only team responsible for managing such incidents. Cross training for the teams involved, for cybersecurity technology skills as well as governance and risk control aspects, is necessary to compensate for skills gap and to speed up the response time.
Mismatched Software Versions
A team that monitors and scans a particular server for vulnerabilities notified my application team of the presence of a vulnerability [CVE-2025-52520] in our Tomcat middleware component. My application team worked with the middleware team (which manages Tomcat) to upgrade the Tomcat component, per the CVE advisory. Post-upgrade, the application team worked with the scanning team to validate that the vulnerability was not showing up in the scan report. However, to the application team’s surprise, the vulnerability was still identified in the report.
According to the scan report, the recommended action was to upgrade to Apache Tomcat 9.0.107. The application team worked with the middleware team to understand the root cause for the discrepancy. It was determined that the application did not use the open source version of Apache Tomcat that the scanning tool based its policy on. Instead, the application used an RHEL vendor-provided version of Tomcat, which already had latest available patch level of 9.0.87. The middleware team confirmed with the RHEL vendor that CVE-2025-52520 is fixed in RHEL Tomcat 9.0.87.
However: the application itself was nonetheless reported as ‘overdue’ to the governance team, despite the fix being in place! The whole exercise was effectively futile. Here, therefore, are my recommendations for avoiding recurrence of such a situation:
- We maintain an inventory of multiple flavors of all software used in the organization. Skill shortfalls relating to feature or version differences are filled with appropriate training.
- Enterprise scanning tools and teams managing such tools are equipped to understand the different flavors of all software products used in the enterprise.
- Scanning tools are configured for scanning vulnerabilities in a specific flavor of software product, to avoid misleading recommendations and resolution paths.
How Skills and People Shortages Elevate Risk
Through our experiences with these two cases, we learned how such scenarios can be avoided through the cross-training of relevant cybersecurity skills and by reviewing the personnel needs of teams that may face similar situations:
- Delayed Identification of the Vulnerability Owner – We had multiple teams involved in both cases – AppDev, SecOps, middleware and the vendor. Even though application owners used and owned the application, they merely use software provided by a vendor having vulnerable component managed internally by a middleware team. Application owners in these cases require extra time to identify the correct owners between AppDev, middleware and the vendor, who could resolve the vulnerabilities.
- Delay in Resolutions – Analysis of a vulnerability and understanding its resolution requires time, especially if it is vendor software. In turn, vendors manage such software for multiple customers and require their own release processes followed for any patch release. In cases where a vendor has already released a patch, it still requires analysis and testing by the middleware team.
- Overstressed Staff – Our Middleware team typically manages the components of multiple applications and tend to delay resolutions until they are prioritized or escalated due to shortages. Once a patch is applied by the middleware team, both it and the AppDev teams need additional time to perform validations and testing. All of this increases stress on current teams.
Conclusions
These cases illustrate that maintaining the security posture of interconnected applications in modern organizations requires all interfacing teams to have relevant cybersecurity skills; all teams need to use a common cybersecurity language. In turn, this requires adequate resources across teams; a shortage in either people or skills may translate directly into cybersecurity gaps. I hope my experiences might help other teams in similar situations.
Veerbhadra Magdum, CCSP, is a system manager with over 20 years of experience building applications and managing the security posture of applications across a variety of enterprise infrastructure architectures. His work focuses on application risk management, application monitoring and application security management.
