Attack Surface Management (ASM) is the ongoing discovery, inventory, classification, prioritization, and security monitoring of an organization’s IT infrastructure. The attack surface is all of the entry points where an unauthorized user or attacker can pull data from.
A Software Bill of Materials (SBOM) can be a powerful component of software security, and that’s why the rise of SBOMs should be good news for product security leaders and their teams. Because these documents are formal records that contain the details and supply chain relationships of the various components used in building software, they provide extensive histories of the software that can help organizations identify potentially risky components or sources.
In previous posts, we’ve discussed how the Software Bill of Materials (SBOM) concept will make a difference in cybersecurity, and why context is needed to generate the most value from these formal records of the details and supply chain relationships of software components. As helpful as SBOMs are in tracking the history of software products and their components, most of these documents remain static. That’s not ideal for a scenario in which there is near constant change.
Vulnerability management is one of the foundational controls that all organizations are required to have out of necessity due to increasing cyberthreats and as a consequence, compliance requirements. Vulnerability management as a practice is fundamental to organizations who want to ensure that their operations run smoothly without any loss of productivity or profits.
In a previous post, we discussed whether a Software Bill of Materials (SBOM) can really make a difference from a cybersecurity standpoint, and the answer is a resounding “yes.” However, while an SBOM provides lots of the information organizations need to know about the components of the software products they buy and use, such a list by itself is not enough. For the SBOM to be really effective, they need to have context as well. Not all software products or vulnerabilities are equal.
We’re hearing more and more about a Software Bill of Materials (SBOM) as a vital tool for increasing software security. With the federal government pushing the idea, there’s no doubt it will remain newsworthy. One of the key questions about SBOMs is will they really make a difference? And how will they make a difference?
Vulnerability patching is the short-term implementation of patches, which are pieces of code added to existing software to improve functionality or to remove vulnerabilities that have been flagged. Patches usually come from vendors of affected hardware or software and IT should apply them to an affected area in a timely manner.
Finding vulnerabilities in software is serious business. Weaknesses in software can lead to security risks such as costly ransomware or phishing attacks, and there are new types of vulnerabilities emerging all the time. The shift to remote and hybrid work models during the past two years has made vulnerability management even more complex—and necessary. Plenty of products are available to help organizations and development teams find vulnerabilities.
We are still recovering from the after effects of Log4j, but there is already a new vulnerability around the corner. PWNKIT, reported by Qualys’ research team, is a major Linux polkit (previously known as PolicyKit) related vulnerability. Like Log4j, which is the logging utility of Java, polkit is a systemd SUID-root program that controls system-wide privileges in unix-like operating systems.
