More vulnerabilities, less manual maintenance: why automated pipelines are essential

A security update becomes available for a library your application uses. Applying it may take minutes. Finding out whether it breaks authentication, a customer workflow or an integration can take much longer.

When every update requires a manual investigation and a carefully coordinated release evening, maintenance becomes a queue. The longer that queue grows, the longer systems may remain exposed.

At HIT, our position is clear: automated pipelines are now essential for maintaining production software at a sustainable pace. Their value depends on the evidence they produce: meaningful tests before release, controlled exposure during rollout and monitoring that can stop a bad change.

From around 50 published vulnerabilities a day to almost 200

The CVE Program recorded 18,375 published CVE records in 2020: an average of 50.2 per day. In 2025, that reached 48,244, or 132.2 per day. For January–June 2026, it lists 35,872 records: 198.2 per day over 181 days. These are HIT calculations from the official CVE publication statistics, accessed on 17 October 2026.

The chart uses period totals divided by calendar days, including leap years. The 2026 bar covers only the first half of the year; it is not a full-year forecast. The source had not yet populated Q3 when checked.

These figures count published records, not vulnerabilities discovered on each day, attacks or flaws affecting your particular application. Changes in reporting coverage and publication practices also influence the totals. The practical implication is a growing volume of disclosures to assess, rather than a direct measurement of your organisation’s risk.

Lifecycle management needs a repeatable path to production

Lifecycle management, or LCM, includes keeping dependencies, runtimes, container images and operating systems on supported versions. It also means planning upgrades before components reach end of support.

We want routine, well-understood maintenance to move through an almost automated process. A scheduled check identifies an update, proposes a small change, builds a versioned release and runs the required checks. Eligible changes can then progress under an agreed policy. Breaking upgrades, destructive migrations and uncertain results go to an engineer for review.

For example, a patch to an HTTP library should trigger more than a successful build. The pipeline should verify login, outbound API calls, timeouts and error handling before allowing the release to advance.

Automation should also help decide what needs attention first. We recommend combining component inventory, actual exposure, vendor guidance and evidence of exploitation. NIST’s April 2026 update illustrates this need for prioritisation: the NVD now prioritises enrichment of selected CVEs, including those in CISA’s Known Exploited Vulnerabilities catalog. An absent NVD analysis is not evidence that a vulnerability is harmless. Source: NIST’s explanation of its updated NVD operations.

Sanity tests are the minimum foundation

A pipeline that builds successfully tells us that the software can be built. It does not tell us that customers can still use it.

We start with a fast, dependable sanity suite covering the essential journeys. Can the application start? Can a user sign in? Are permissions enforced? Can a representative transaction be completed and read back correctly? Can a critical background job finish?

These checks should run against the actual release candidate in a representative environment. “The homepage returns HTTP 200” is useful, but it is not sufficient evidence that an application works.

Regression and integration tests make broader automation credible

For dependable unattended updates, we recommend a broader set of checks:

• Regression tests: protect existing business behaviour, including calculations, validation, permissions and previously fixed defects.
• Integration tests: verify interactions with databases, queues, identity providers and external APIs, including failures, retries and timeouts.
• Security and compatibility checks: inspect dependencies and images, test access boundaries and identify unsupported combinations.

For important integrations, mocks alone cannot establish compatibility with the real service. Combine controlled test doubles with contract checks or sandbox integration tests where available. Use isolated data and prevent test activity from sending real customer messages or triggering real transactions.

The suite also needs maintenance. Flaky tests, stale fixtures and ignored failures weaken release decisions. At HIT, we focus on trustworthy coverage of critical behaviour, with clear ownership of failures. If a required check fails, the pipeline stops.

Canary releases limit how far a problem can spread

Even a strong test suite cannot reproduce every production condition. A canary release exposes a limited portion of real traffic to a new version, evaluates it and uses that result to decide whether rollout should continue. Google’s SRE workbook describes this approach and the importance of comparing the canary with the unchanged control group. Reference: Google SRE, Canarying Releases.

For a suitable service, HIT might configure an illustrative progression of 1%, 5%, 25% and then 100% of traffic. These are starting points for discussion, not universal safe thresholds. Each stage needs representative traffic, enough observations and time to expose relevant failures, including background work.

A low-volume application may need a longer observation window and synthetic checks. Shared databases, global configuration and irreversible writes require special care: a small traffic percentage does not automatically isolate their consequences.

Monitoring must be able to change the rollout

A dashboard that someone might check tomorrow does little to protect a release happening now.

We connect rollout decisions to version-specific signals: failed requests, latency, resource pressure, queue delays and the success rate of important business journeys. Compare the candidate with the stable version and with agreed service objectives. An overall average can hide a failing canary.

If those signals deteriorate beyond the agreed limits, automation should halt promotion and, where safe, return traffic to the previous version. Missing or inconclusive telemetry should pause progression rather than count as success. The responsible team receives an actionable alert and the evidence needed to investigate.

Rollback must be designed and rehearsed. Returning to an older application version does not undo corrupted data or reverse a destructive schema migration. Backward-compatible migrations, tested backups and recovery procedures remain part of the design.

What HIT brings to the process

We help turn maintenance into a repeatable operational capability: map components and ownership, define update priorities, build the pipeline, establish meaningful tests and connect staged releases to monitoring and recovery.

We start with the most important application journeys and the updates that can be automated responsibly. We then expand coverage and automation as the evidence improves. The outcome is measured through practical results: time to remediate relevant vulnerabilities, time spent on routine maintenance, failed changes and recovery time.

More vulnerability disclosures make manual maintenance harder to sustain. Automated LCM, trustworthy tests, canary releases and responsive monitoring work together to reduce exposure and limit production impact. They cannot promise zero incidents, but they give teams a controlled way to keep software current.

At HIT, we build the confidence to maintain software continuously, with people focused on the exceptions that need their judgement.