To protect an airline’s security across applications, the main goal of an engineering team is to ensure the highest-risk vulnerabilities are assigned, tested, and safely remediated before they escalate into a serious operational disruption.
The insights below come from one of our Cloud Security Engineers who is helping a Fortune 500 airline automate vulnerability management across a large AWS environment.
Critical vulnerabilities should never reach production
In airline environments, a single security issue can affect hundreds of applications supporting employees, airport operations, and other extremely important functions. Hence, a critical vulnerability should always be fixed before reaching production environments. However, enforcing this never happens poses a few challenges:
- Airline IT environments are extremely complex. For context, the airline we work with manages approximately 1,400 repositories spread across dozens of applications, multiple Linux distributions, and more than 30 AWS services, including S3, EC2, AppSync, Kinesis, and Step Functions.
- Vulnerabilities can appear almost anywhere. They may exist in application code, third-party dependencies, operating system packages, cloud configurations, or connected services. Each application can include hundreds of dependencies, APIs, cloud services, infrastructure configurations, and integrations.
- Applications are constantly being updated. As components are updated, deployed, and connected to other systems, potential entry points for attackers also change.
- The same vulnerability can represent different levels of risk. Its urgency depends on where it appears, which application it affects, whether it is exposed to the internet, and whether the vulnerable component is running in production.
To exemplify the last point better, let’s look at a case where an airline finds the same vulnerable software package in two places:
- An internal training website: Only airline employees can access it, the app only contains fake passenger information, and it is not connected to important operational systems. If someone exploited it, the damage would likely be limited.
- The public booking website: Millions of travelers use it to search for flights, enter personal information, make payments, and manage reservations. If someone exploited the same weakness here, they could steal customer data, interrupt ticket sales, or prevent passengers from accessing their bookings.
Clearly, the booking site should be fixed first as it affects airline customers and reservations. But how can airlines define which issue is more critical to fix, in a systematic way?
Airlines use automated tools to score the level of risk
Security teams cannot manage vulnerabilities without first having a clear and current view of what is happening across their applications and cloud environment. Thus, airline companies begin the process by running scanning tools to find vulnerabilities, and the risk engines then classify findings into four severity levels to determine what to fix first:
| Severity | What it means | When it gets fixed |
|---|---|---|
| Critical | Exploitable now, high impact | This sprint. Blocks any release. |
| High | Serious, likely exploitable | This sprint. Blocks any release. |
| Medium | Real, but lower risk or harder to exploit | Backlog, planned work. |
| Low | Minor, low impact | Backlog. |
The most interesting part of the story is that, unlike organizations that may temporarily accept or defer risk for later, airlines actually have a zero-tolerance policy: if an application has an unresolved Critical or High finding, the deployment is blocked until the issue has been investigated and safely fixed.
Regarding tech stack, based on our experience working inside the client’s environment, there are four extremely useful vulnerability management tools:
- Wiz: A cloud security platform that continuously monitors applications, workloads, and cloud resources across Development, QA, and Production. Each finding is assigned a severity level, helping engineers quickly understand which issues need immediate attention.
- Veracode: An application security platform used to scan application code for vulnerabilities. In this environment, teams manually submitted code snapshots and reviewed the results after each assessment.
- Dependabot: A GitHub tool that helps teams remediate vulnerable software dependencies. It can recommend a safer version, create a branch, and open a pull request automatically.
After using all these tools, once the finding has been validated and prioritized, it needs to be assigned to a clear owner so it can get fixed, using tools such as Nucleus to automate ownership assignment and remediation. Let’s do a deeper dive into how vulnerability alerts are resolved in practice.
Security engineers follow a structured process to triage vulnerabilities
Once a security scanner identifies a vulnerability, engineers still need to understand where it exists, determine how much risk it creates, assign the right technical owner, implement a safe fix, and verify that the vulnerability has actually been removed.
Here’s a bit more insight into the vulnerability remediation and resolution process:
- Reviewing and prioritizing the finding. The team first looks at how severe the vulnerability is, which application it affects, where it was found, and what could happen if it were exploited. A Critical issue in Production usually needs immediate attention, while a lower-risk finding may be added to the backlog.
- Creating a clear remediation record. Each finding is documented in a ticket with the affected system, severity, owner, deadline, and recommended fix. For larger remediation efforts, the team can create subtasks for each vulnerability and include the pull requests, remediation steps, and evidence of what was changed.
- Assigning the right technical owner. Security engineers help identify and prioritize the problem, but they may not be the ones who fix it. Depending on the issue, the work may go to a cloud engineer, developer, DevOps engineer, QA specialist, or infrastructure owner.
- Implementing and testing the fix in Development. The team first applies the change in the Development environment. This gives engineers a safe place to update the code, rebuild the application, and see whether the fix breaks anything without affecting customers or live operations.
- Promoting the change to QA for validation. Once the fix works in Development, it moves to QA, which is designed to behave as closely as possible to Production. The team tests the application again and runs another security scan to confirm that the vulnerability is gone and that no new issues were introduced.
- Enforcing security gates before Production. A change should only move into Production after it passes functional testing, security scans, and release approvals. In Mariano’s environment, Wiz and Veracode automatically block the deployment if any Critical or High vulnerabilities remain unresolved.
- Deploying, verifying, and documenting the result. After the fix reaches Production, the team checks that the application is working correctly and scans it again to confirm the vulnerability is no longer present. The ticket is then updated with the results, evidence, and details of what changed.
- Automating repetitive remediation where possible. Many vulnerabilities come from outdated software dependencies. Tools such as Dependabot can automatically create a branch and open a pull request with the recommended update. An engineer still needs to review and test the change, but the automation removes much of the repetitive work and helps reduce the backlog of Medium and Low findings.
Key lesson here: remediation is only complete when the fix has been tested, approved, deployed to Production, scanned again, and verified to no longer create an unacceptable risk.
Partnering with a vulnerability management services provider can accelerate remediation
Ultimately, the end-to-end vulnerability management process until closing tickets is a team effort. Based on our experience, a large commercial airline usually requires a full team of 6-12 people, including key security roles such as developers, cloud engineers, infrastructure teams, and QA specialists who help fix and validate the findings.
Since setting up an entire team can be expensive and time-consuming, a great option to accelerate remediation is to partner with a nearshore vendor specialized in security and compliance. A staffing partner can sometimes offer roles such as a Vulnerability Management Lead or Cloud Support Engineers in an outstaffing model. Additionally, these vendors may also be able to provide executive roles like a Fractional CISO to guide the entire vulnerability management program and improve the overall security of the organization.
Frequently Asked Questions (FAQ)
What is vulnerability management in aviation?
Vulnerability management in aviation is the ongoing process of finding, evaluating, prioritizing, fixing, and documenting security weaknesses across an airline’s applications, cloud environments, infrastructure, and software dependencies.
Because airlines operate large, connected technology environments, vulnerability management is not a one-time scan or annual exercise. New vulnerabilities are discovered constantly, applications change frequently, and the same software may exist across Development, QA, and Production. The goal is to continuously reduce risk while keeping critical systems available and reliable.
What is the difference between vulnerability scanning vs. vulnerability remediation?
Vulnerability scanning is the process of identifying potential security issues. Instead, remediation is the engineering work required to safely remove or reduce the risk. Once a scanner finds a vulnerability, engineers still need to validate the finding, understand what introduced it, identify the affected application or cloud resource, determine whether a safe fix is available, and assign the work to the right owner. The team then applies the change, rebuilds the application if necessary, tests it in Development and QA, scans it again, and confirms that the vulnerability has been removed.
How do airlines prioritize software vulnerabilities?
Severity is usually the starting point, but it does not provide enough context on its own. Teams also need to consider where the vulnerability exists, whether the affected system is running in production environments, how exposed it is, what data it handles, whether there is known exploitation, and how serious the operational impact could be.
For example, the same vulnerable dependency may represent limited risk inside an isolated dev environment but become urgent when it appears in an internet-facing prod application used by customers or airport employees. Effective prioritization combines the scanner’s technical rating with the real business and operational context of the affected system.
What vulnerabilities should block a Production release?
In the workflow described in this blog, unresolved Critical and High vulnerabilities block a release from moving into Production. These findings may expose sensitive data, interrupt important operations, or create an entry point into connected systems.
Medium and Low severity findings are documented, assigned to an owner, and added to the remediation backlog. However, severity should not be the only consideration. A Medium finding affecting an exposed, business-critical application may require faster action than a High finding inside a tightly isolated test environment.
Why can’t teams simply upgrade every vulnerable dependency immediately?
A dependency upgrade may remove the security issue, but it can also introduce compatibility problems, break an integration, affect another package, or change how the application behaves.
That is why even an apparently simple update needs to be reviewed and tested. Engineers usually apply the change in Development, rebuild the application, run functional tests, move it into QA, and scan it again. Only after the team confirms that the vulnerability is gone and the application still works correctly should the change move into Production.
Can vulnerability remediation be fully automated?
Only partially. Security platforms can identify, score, and prioritize vulnerabilities, while tools such as Dependabot can prepare dependency updates, create branches, and open pull requests automatically.
However, these tools do not fully understand the application’s business logic, custom integrations, operational importance, or release constraints. Engineers still need to review the proposed change, resolve compatibility issues, test the application, verify that the vulnerability was removed, and decide whether the fix is safe for Production.
Why can Medium and Low vulnerabilities remain in the backlog?
Medium and Low findings are generally less urgent than vulnerabilities that could block a release or directly expose a Production system. At the same time, the engineers responsible for remediation are often also supporting Production incidents, maintaining cloud infrastructure, managing deployment pipelines, and delivering new application features.
Even when the fix is straightforward, completing it may require updating the code, rebuilding the application, opening a pull request, running tests, rescanning the system, and coordinating the release. Across hundreds or thousands of findings, that becomes a significant amount of engineering work.
How can nearshore vulnerability management services help reduce a large backlog?
Hiring a vendor that can provide managed vulnerability management services is a great option to quickly onboard additional engineering capacity to address unresolved backlogs. An airline may consider this type of service when the volume of vulnerabilities is growing faster than the internal team can manage, Critical and High findings are delaying releases, or remediation work is competing with other engineering priorities.