Paladin aims to help developer operations (DevOps) teams safeguard their applications and data — both in testing and production environments. The platform does this by delivering visibility into the security posture of an enterprise’s multi-cloud operations.
The goal: automate the detection and remediation of security policy violations, which may include anything from unauthorized access or misconfigurations to insecure APIs.
It’s great to see new thinking in this area, especially with DevOps-friendly open-source solutions, said Casey Bisson, head of product and development enablement at BluBracket. Bisson said open source solves two problems: by being able to inspect the code, it’s easier to trust. And, because it’s something DevOps teams execute on their own infrastructure, rather than a SaaS offering, it’s easier for them to manage the keys and permissions grants to access that infrastructure.
Bission said the BluBracket team does see vulnerabilities in open source, but the shift to open source has been a great boon for improving security. Bisson said all software has some bugs and security vulnerabilities, but the additional eyes lately on open source help identify and fix those risks more quickly and effectively than in closed-source solutions.
“Checkov, an open source infrastructure-as-code policy enforcement engine by BridgeCrew, has long been the foundation of the cloud security efforts of many teams,” Bisson said. “It integrates well into the build pipeline, and DevOps teams test and adopt it without having to grant permissions to external services or navigate the hoops that can entail in some orgs. Paladin Cloud actually looks at the running infrastructure, not the IaC, so it can find violations in what’s actually running, not just what was declared in the Terraform or Pulumi config.”
Mark Lambert, vice president of products at ArmorCode, added that as the software supply chain gets more complicated, it’s critical for security teams to know what open source they are indirectly utilizing as part of third-party libraries, services or tools. Lambert said here’s where a software bill of materials (SBOM) comes in.
“By requiring a disclosure of all embedded technologies from vendors, security teams can perform analysis of those libraries to further assess risk and react appropriately,” Lambert said. “Remember, open-source risk cannot be thought of as a single point in time. The recent Log4j vulnerability demonstrated that software that was utilized for years, and deployed within an uncountable number of systems, was discovered to be vulnerable to remote code execution. This requires an ongoing analysis of open source usage long after the software has been deliver out of the pipeline.”