MODERNIZATION BENEFITS
Prioritizing Security Risks in Legacy Software
Identify unsupported components, update blockers and access boundaries. Decide which risk needs attention first.
Updated:
SHORT ANSWER
Components that cannot be updated and unclear access rights can make remediation harder. Plan modernization around a viable update path, controls with clear owners and prioritized fixes.
Why it matters
In Verizon's 2025 DBIR, known initial access vectors in non-Error, non-Misuse breaches include vulnerability exploitation at 20%, credential abuse at 22% and phishing at 16%. The exploitation share increased 34% relative to the previous report.
Source: 2025 Data Breach Investigations Report — Executive Summary · Verizon · Published: · Accessed: Figure 1 covers 9,891 breaches; reporting period November 1, 2023–October 31, 2024. The 34% is relative growth, not percentage points. This does not measure every business's breach probability.
CISA identifies unsupported software in critical infrastructure and national critical functions as a dangerous practice, emphasizing the risk in internet-accessible technologies.
Source: Bad Practices · Cybersecurity and Infrastructure Security Agency (CISA) · Published: · Accessed: · Last checked: Official security guidance, not a numerical risk or modernization outcome measurement. CISA encourages all organizations to address these practices.
In W3Techs’s 13 October 2026 table, PHP is used by 69.7% of websites with a known server-side language. Among PHP websites, versions 8, 7 and 5 account for 64.7%, 27.4% and 7.8%.
Source: Usage Statistics and Market Share of PHP for Websites · W3Techs · Published: · Accessed: Daily observation with different denominators for language use and version shares. Read the security context with the php-7-4 and php-5-6 EOL records: PHP Group support has ended (https://www.php.net/eol.php). This does not measure commercial support or vulnerabilities in individual websites.
In Red Hat’s second application modernization report, organizations currently modernizing report benefits in security (58%), scalability (53%) and reliability (52%).
Source: The state of application modernization, second edition · Red Hat · Published: · Accessed: Red Hat-sponsored self-report survey of 1,000 IT respondents in the US, UK and English-speaking Asia-Pacific, October–November 2023. Percentages apply to the modernizing subgroup; they establish neither causation nor outcomes from our service.
What happens when a component cannot be updated?
An old dependency can block an update, while shared accounts can leave it unclear who performed an action. Starting with these concrete problems gives the first security work package a clear scope.
What can change in updates, access and audit records?
- Updatable components: Resolve version and dependency blockers to create a maintainable update path.
- Access by role: Define the data and operations each user needs for their work.
- Traceable actions: Keep records that show who made an important change, when and what changed.
Which security issue should be reviewed first?
Choose a component that cannot be updated or an operation with unclear permissions. Review the affected users, data and current control in a health check, then define the remediation step.
Not every finding requires a rewrite. An applicable patch, corrected permission or isolated component may allow a smaller remediation scope.
What changes when a query is fixed?
The PHP order lookup experiment runs the same six functional and access checks against three implementations. Parameterizing the query alone did not prevent direct access to another tenant’s order.
| Implementation | Checks passed | What changed? |
|---|---|---|
| Input appended to SQL | 2 / 6 | Query errors and unauthorized rows were observed. |
| Parameterized query | 5 / 6 | Input could no longer alter SQL structure; tenant isolation was still missing. |
| Parameterized, tenant-scoped query | 6 / 6 | All six checks returned the expected results. |
The frontend text-rendering experiment compares input interpreted as HTML with literal text output. These results show why implementation changes and checks for the required behavior belong together.
Measurement approach
The PHP experiment checks normal lookups, missing records, an apostrophe, two SQL injection inputs and cross-tenant access against the same synthetic order data. Inputs and returned rows are published for all six functional and access checks. A separate frontend experiment examines six text/HTML inputs. These are not tests of a client system or whole-system security approval. Industry sources are not results of these experiments; see the measurement principles.
Evidence from the lab
Passing functional and access checks
↑ 3×Higher is better · 1 single measurement
Measurement method →Explore your own situation
Frequently asked questions
Does unsupported software mean a system has been compromised?
No. Support status and an actual breach are different facts. Checking a product version's support record does not demonstrate a vulnerability in a particular system or prove that an attack occurred.
Is security work complete after a clean scan?
No. The result applies to the scan's scope, tool, version and date. Access permissions, audit records and restoration from backups require separate checks.
How should before-and-after finding counts be compared?
Record the scan scope, tool version and finding categories. A lower total should not be presented as an improvement without explaining any changes to scope or method.
Where do security tests run?
We agree on the test environment and scope together. Checks requiring production access have explicit authorization, a testing window and stop conditions; suitable checks are rehearsed in a separate test environment first.
Does this page provide certification or security approval?
No. The published experiments show results for specific input and access checks. A checklist does not replace a legal compliance determination, certification or security approval covering the entire system.