Hear about the state of open source in our Red Hat partner webinar, discover our approach to threat modeling, and learn how to secure Node.js applications.
Robust software security requirements help you lock down what your software does so that it can be used only as intended. Learn how to build your own.
This week we released a new version of Black Duck OpsSight, a solution for vulnerability detection and alerting in production environments. When we introduced Black Duck OpsSight for OpenShift in November, we made it possible for customers who use Black Duck Hub as an integral part of their SDLC security process to also monitor the open source security of their application deployment environments.
At Black Duck, we’ve been excited to participate in the flurry of growth in the .NET ecosystem. Our Visual Studio Extension helps developers detect open source risks early, when it is easiest and most cost-effective to eliminate them. However, in some cases, a Visual Studio project or any build file or other composition metadata may not be available. Perhaps an application’s source code (and the component data that comes with it) has been lost. Perhaps the application was provided by a vendor who has never made the source code available in the first place. Or perhaps, in addition to scanning application dependencies, we want to include the actual production runtime in our scan. Is such component analysis possible?
At a security conference this week, researchers complained about the CVE backlog at MITRE, related to the organization’s handling of new vulnerabilities, and the difficulties of getting a CVE assigned.
Posted in Software Architecture & Design
Here are 4 best practices to help you create an issue-resistant free and open source software vulnerability management program while remaining agile.
Security, including software security, is very much rooted in a control culture. Security concepts such as firewall rules, access controls, and input validation are all about getting and keeping control—we frequently refer to these as security controls. Standardized processes that promote stability and order are also highly valued components of security. This control culture often causes friction when security is introduced in agile development teams that have a very different culture. Working with the culture, not against it Agile software development is more about culture than a set of processes, although it is often mistaken for the processes it is associated with (e.g., scrum). The values and beliefs that define the idea of agile are described in the Agile Manifesto. This manifesto does not define a specific development process, but rather the values and priorities that underpin agile software development.
Until recently, there has not been real pressure to have supply chain software vendors attest to the validity of their wares. But with the introduction of software into automobiles, television sets, and medical devices, software integrity has taken on greater meaning. Many industries have specific hardware procurement requirements for parts introduced into their supply chains, but what about software?
We discovered a flaw that enables a man-in-the-middle attack, or MitM attack, on a secure connection between a Socket.IO server and client.
I recently discovered an important security issue in Socket.IO—a zero-day vulnerability that allows a man-in-the-middle attack on TLS-protected communication between a Socket.IO client and a Socket.IO server. I find this issue rather interesting because it shows how unfortunate design decisions can unintentionally lead to insecure default configuration. This also highlights the dangers of not following secure design principles.