Just like you’d find all the ingredients on a package of food, a software bill of materials is a list of all the components contained in a software product. Vendors typically create these bills to describe what the components are. In addition, a Software Bill of Materials also includes information about these components’ dependencies and their hierarchical relationships.
Given the holiday season, I suppose it’s timely to label the recent Log4j vulnerability as the “vulnerability gift that just keeps on giving.” A quick scan of the headlines is all one must do to understand my sarcasm: Cyberscoop reports that The US Cybersecurity and Infrastructure Security Agency (CISA) warns that the Log4j vulnerability will likely affect hundreds of millions of devices and that the vuln “is one of the most serious…if not the most serious” seen by t
The ability to effectively manage vulnerabilities in an efficient and strategic manner is critical for companies. The ongoing practice of identifying, classifying, prioritizing, and fixing software vulnerabilities should be a key component of the development process. If it’s not, teams might turn out applications that contain vulnerabilities with consequences ranging from mild annoyances to disastrous security breaches.
The dust refuses to settle over the Apache Log4j2 vulnerability (CVE-2021-44228) commonly known as Log4Shell. Rezilion is closely monitoring the situation and in this blog post, we will provide relevant information and updates that have surfaced since Log4Shell entered the IT world by storm. If you want a deeper understanding of the vulnerability itself, you can refer to our previous blog post around the topic.
By Yotam Perkal, Vulnerability Research Lead, Rezilion It has been hard to miss the recent warnings about the newly discovered remote code execution (RCE) vulnerability CVE-2021-44228, also known as Log4Shell. The vulnerability, originally disclosed on November 24th by Chen Zhaojun of Alibaba Cloud Security Team, is already being actively exploited in the wild. Why is this vulnerability such a big deal?
Like waistlines after a large holiday meal, legacy programming code can become bloated with useless lines of code resulting in features that are unnecessarily long or slow, due to a large amount of memory and RAM. Useless code might be libraries that contain new code and repetitive code from older versions of software, or service binaries.
In the software development process, knowing exactly which vulnerabilities to focus on and which to downplay, or ignore because they pose no significant threat, is vital for increasing efficiency and applying fixes quickly and effectively. Security can be tricky in a DevOps environment, because if it’s applied too stringently, can keep products from being released in a timely manner. If it’s treated too passively, risks can quickly accumulate.
DevSecOps is a hot term that many security leaders and executives are talking about. However, this process of embedding security into every stage of the software development life cycle (SDLC) is, like many technology undertakings, also subject to a number of misconceptions and myths. To successfully implement a DevSecOps program within an organization, it is important to enter into the effort with eyes wide open, and to understand that some of what you have heard about it might be wrong.
Today we are thrilled to announce that Rezilion will be featured as one of the launch partners for Amazon Inspector security assessment service. At this same time, we are also unveiling our agentless deployment mechanism across AWS instances: a turning point in our customer experience, empowering 1-click deployment of our toolset for the world’s largest cloud computing community.
