Venafi Survey: How Concerned Are Executives About Protecting Security Software Build Environments?
Venafi Survey: How Concerned Are Executives About Protecting Security Software Build Environments?
The SolarWinds breach changed the game on how companies perceive software assurance and who should own it. According to ENISA, supply chain attacks, such as SolarWinds, Codecov and Kaseya, are expected to increase by a factor of four in 2021.
To measure how organizations are planning to improve software assurance, Venafi conducted a survey that evaluated the opinions of more than 1,000 IT and development professionals, including 193 executives with responsibility for both security and software development. Surprisingly, this survey revealed a glaring disconnect between executive concern and executive action.
The survey found that 94% of executives believe there should be clear consequences for software vendors that fail to protect the integrity of their software build pipelines. These consequences included penalties such as fines and greater legal liability for companies proven to be negligent.
The Venafi survey found that:
- 97% of executives believe that software providers need to improve the security of their software build and code signing processes.
- 96% of executives think that software providers should be required to guarantee the integrity of the code in their software updates.
Despite this concern about enforcing liability for software assurance, many organizations do not seem to know how to measure software security or enforce it within their organizations. In fact, most have done little to change the way they evaluate the security of the software they purchase and the assurances they demand from software providers.
The Venafi survey also found that:
- 55% of executives report that the SolarWinds hack has had little or no impact on the concerns they consider when purchasing software products for their company.
- 69% of executives say their company has not increased the number of questions they are asking software providers about the processes used to assure the security of their software and verify code.
Executives are clearly much more concerned about their vulnerability to software supply chain attacks and aware of the urgent need for action. However, the survey results show that they are not taking action that will drive change. “There is a clear disconnect between concern about supply chain attacks and improving security controls and processes to mitigate this risk,” said Kevin Bocek, vice president of security strategy and threat intelligence at Venafi.
It’s interesting to think about why that disconnect might be happening. For one, there is a lack of understanding about which teams should own software assurance within organizations.
According to Venafi survey responses;
- Within their own organizations, executives are split on who is responsible for improving the security within their own software development organizations, with 48% saying IT security is responsible and 46% saying development teams are responsible.
But in addition to that, I think there is an overall lack of understanding about how to evaluate the security of software. Most executive may simply not have access to the criteria that their teams need to evaluate the security of software that they will purchase or use within their organization. In response to that void, Venafi has teamed up with Veracode with support from Sophos and Cloudbees to define a vendor-neutral map of standard controls. These diverse controls dramatically reduce risk and align with agile, high performance software development pipelines.
Executives and their teams may be able to use the following controls to measure the security of software that they wish to deploy in their enterprises.
- Control-1: Restrict administrative access to CI/CD tools
Ensure that only authorized persons can make administrative changes to the CI/CD system.
- Control-2: Only accept commits signed with a developer GPG key
Require commits to be signed with a developer GPG key helps to increase the burden on the attacker seeking to insert malicious code.
- Control-3: Automation access keys expire automatically
Ensure that access to keys used by automation expire periodically to create a shorter window of attack when keys are compromised.
- Control-4: Reduce automation access to read-only
CI systems should have read access only to source code repositories following the principle of least privilege access.
- Control-5: Only dependencies from trusted registries can be used
Configure the dependency manager to only allow connections to an authorized list of registries to keep malicious packages in the public registries from entering the pipeline.
- Control-6: Any critical or high severity vulnerability breaks the build
Use static application security testing (SAST) to identify serious security issues, including poor cryptographic practices, hard-coded credentials, and injection vulnerabilities.
- Control-7: Store artifacts in a repository in development, stage and production
Repositories for dev, stage and production should be segregated so that role-based access control can ensure least privilege at each stage.
- Control-8: Validate artifact digest
Before an artifact is deployed in any environment, its digest should be validated against the artifact in the repository to ensure that it has not been compromised.
- Control-9: Pull-requests require two reviewers and a passing build to be merged
Require two code reviews at the time of pull-requests, including one from a developer who is an owner of that code.
- Control-10: Artifacts in higher repositories are signed
Require signed artifacts to ensure that untrusted binaries are not deployed to customer environments and allows validating the source of the binaries.
- Control-11: Available container images don’t have high or critical vulnerabilities
Test the container images into which applications are packaged for deployment for vulnerabilities.
- Control-12: Validate artifact signatures and digests
Validate the signature of an artifact against the digest to ensure that it was not tampered with in the repository and that the artifact being deployed is the same one that was tested.
- Control-13: Scan deployed images in production
Validate pre-production controls in production to ensure that the prior controls were followed for all software in production.
- Control-14: Validate Kubernetes resource manifests
Control and validate Kubernetes resource manifests just as the actual images are.
- Control-15: Ensure build environments are ephemeral and immutable
Build environments should be defined in code with automated creation and teardown, and that a fresh environment is created for every build.
Visit the full GitHub page to see the full list of controls and full details on potential exposure.
“Executives are right to be concerned about the impact of supply chain attacks,” noted Bocek. “These attacks present serious risks to every organization that uses commercial software and are extremely difficult to defend against. To address this systemic problem, the entire technology industry needs to change the way we build and buy software. Executives can’t treat this as a just another technical problem—it’s an existential threat. C-level executives and boards need to demand that security and development teams for all commercial software vendorschange their processes so they can provide clear assurance about the security of their software.”
Related Posts
Like this blog? We think you will love this.
Microsoft Backs Off Internet Office Macro Ban [Update]
Microsoft disabled macro years ago by default
Read More
About the author
Scott Carter
Scott is Senior Manager for Content Marketing at Venafi. With over 20 years in cybersecurity marketing, his expertise leads him to help large organizations understand the risk to machine identities and why they should protect them
Read Posts by Author
