Which factors are currently impeding your efforts to patch the Log4j vulnerability? (Select all that apply.)

Threat Intelligence & Incident ResponseThreat & Vulnerability Management

Difficulty determining the extent of our exposure17%

Difficulty determining if third-party vendors have been affected44%

Third-party vendors who are unable or unwilling to patch Log4j47%

Lack of support26%

Lack of patch management controls17%

New versions that contain breaking changes12%

Affected software is no longer maintained16%

Insufficient human resources12%

Current update processes slow down remediation7%

Transitive dependencies are unclear6%

Software inventory is not updated10%

Patching Log4j has been deprioritized4%

Patching requires too much downtime4%

Other (Please share below!)2%

456 PARTICIPANTS
3.4k views

Content you might like

What models are in place for risk partners based in Line 2? What are the jobs to be done? How do they operate? What does the structure/operating rythms look like?

Read More Comments

With Gartner highlighting the urgency of post-quantum cryptography (PQC), I would like to know if there are other members of the group already involved in the discussion or in the planning to face the threat of attacks like 'harvest-now, decrypt-later'?

A common challenge in our risk-tiering framework for suppliers is that even the lowest risk tier still requires processing.
Has anyone implemented a "not relevant" risk tier in their model?
This tier would apply to vendors posing genuinely negligible security risk.

Vulnerability patching is now a full-time job.

Strongly agree9%

Agree60%

Neutral20%

Disagree5%

Strongly disagree3%

Unsure (please comment)

View Results

Which units of time do you use to measure speed of incident detection?

Seconds / minutes19%

Hours74%

Days / weeks5%

Other (specify in comments)

View Results