Research from security shop Veracode revealed that the vast majority of vulnerable apps may never have updated the Log4j library after it was implemented by developers as 32 percent were running pre-2015 EOL versions.
Prior investigations from Veracode also showed that 79 percent of all developers never update third-party libraries after first introducing them into projects, and given that Log4j2 – the specific version of Log4j affected by the vulnerability – dates back to 2014, this could explain the large proportion of unpatched apps.
The researchers believe this illustrates a minority of developers that acted quickly when the vulnerability was first disclosed, as was the advice at the time, had returned to older habits of leaving libraries untouched.
If Log4Shell was another example in a long series of wake-up calls to adopt more stringent open source security practices, the fact that more than one in three applications currently run vulnerable versions of Log4j shows there is more work to do.
When it was first revealed, the vulnerability in Log4j catalyzed widespread fear in the infosec community, given its critical nature and the number of organizations whose software relied on it – a figure Veracode believed to have been around 88 percent at the time.
Log4Shell did cause some high-profile issues, though, such as an attack on a US government network at the hands of Iranian state-sponsored cybercriminals, and the Belgian defense ministry mere weeks into the furore.
The original article contains 670 words, the summary contains 237 words. Saved 65%. I’m a bot and I’m open source!
This is the best summary I could come up with:
Research from security shop Veracode revealed that the vast majority of vulnerable apps may never have updated the Log4j library after it was implemented by developers as 32 percent were running pre-2015 EOL versions.
Prior investigations from Veracode also showed that 79 percent of all developers never update third-party libraries after first introducing them into projects, and given that Log4j2 – the specific version of Log4j affected by the vulnerability – dates back to 2014, this could explain the large proportion of unpatched apps.
The researchers believe this illustrates a minority of developers that acted quickly when the vulnerability was first disclosed, as was the advice at the time, had returned to older habits of leaving libraries untouched.
If Log4Shell was another example in a long series of wake-up calls to adopt more stringent open source security practices, the fact that more than one in three applications currently run vulnerable versions of Log4j shows there is more work to do.
When it was first revealed, the vulnerability in Log4j catalyzed widespread fear in the infosec community, given its critical nature and the number of organizations whose software relied on it – a figure Veracode believed to have been around 88 percent at the time.
Log4Shell did cause some high-profile issues, though, such as an attack on a US government network at the hands of Iranian state-sponsored cybercriminals, and the Belgian defense ministry mere weeks into the furore.
The original article contains 670 words, the summary contains 237 words. Saved 65%. I’m a bot and I’m open source!