of CISOs say application teams sometimes bypass vulnerability scans to speed up software delivery
of CISOs are not completely confident that applications have been fully checked for vulnerabilities before going live in production.
Siloed and limited viewpoint
Most security products have a siloed view of vulnerabilities, and thus, they lack an integrated view of risk. This requires you to utilize multiple products — different products for different environments — and then stitch things together. This problem has been getting worse in recent years, not because security products are getting worse, but because operating environments have been getting more complex and applications more distributed, both of which exacerbate the problem of silos.
An example of a siloed security product is one that is sold by a specific public cloud provider. If your application is comprised of microservices that communicate across cloud boundaries, that security product will not be able to assess your entire application or understand what it connects to.
An example of a limited scope security product is a vulnerability scanner that can’t see inside running containers to detect which libraries are actually being used by the application. As a result, the scanner produces either no information or generates many false positives.
This problem applies even to the latest generation of “cloud workload protection platforms” that were designed with containers in mind. They are only able to scan container images when they are at rest in registries or look at the Docker file manifest. Without knowing which libraries are being used by the application in runtime, and how the cloud workload protection platforms cannot accurately distinguish between a potential vulnerability and a real risk.
Comparing the characteristics of modern development environments to common security tools, several areas of incompatibility are apparent:
Short lifespan makes it hard for traditional security tools to monitor them in production environment, resulting in visibility gaps.
Opaque to many traditional security tools which can’t observe inside the application at runtime. Relying on just an inspection of the Docker file results in many false positive vulnerability detections.
Static application scanning tools can’t identify which parts of the open-source software packages are actually used by the application, or how they are used. This results in many false positive vulnerability detections.
Rapid software development and release cadences
Slow security tools require developers to wait for results, which delays the release. Or, security tests will be intentionally skipped to remain on schedule.
False positives waste time and frustrate developers.
Many security tools can’t see beyond cloud boundaries; thus, they can’t give you a complete picture of your application, and don’t let you enforce security policies consistently across boundaries.