10 Keys To Securing Software Release and Delivery

The failure to provide adequate security for software releases and delivery is becoming costlier day by day, and the impact is enormous: business disruption, lost sales, damaged reputations, frustrated users, and more.

Security breaches can happen within any stage of the software delivery supply chain and not just at the code or infra level. The illustration below provides insights into some of the attack vectors that lead to intentional or accidental breaches and where vulnerabilities can be injected into the end-to-end software supply chain (from code to cloud). 

Assessing and Addressing Attack Vectors Using Appropriate Security Checks

Ideally, these breaches or vulnerabilities can be prevented by inserting automated security checks at different stages within your end-to-end workflow. Following are 11 security checks and where to apply them to counter the attack vectors (please refer to the illustration and the description below).

1. Vulnerability Scanning and Static Code Analysis

Today’s enterprises use specific tools like Sonarqube, Appscan, etc., to identify vulnerabilities within code. If this process is automated with a business rule, then a policy can be enforced to block deployment without scanning, or the scanning stage is successful. In fact, enterprises operating within regulated industries, such as banks, must ensure no deployments occur without the code being scanned, and they must furnish an audit report for each deployment within a specific timeframe. With automated vulnerability scanning, if any breaches are discovered, an appropriate action, such as terminating the pipeline, can be taken instantly. 

2. Securing, Verifying, and Attesting Builds

This stage, which is often overlooked within the software supply chain, can be used to improve kernel security and avoid vulnerabilities that enable successful security attacks. These vulnerabilities can be injected through dependencies or third-party libraries required for build creation without the knowledge of DevOps or engineering teams. This can be prevented by scanning the dependency files and applying spoof checks to ensure builds are verified. Builds can then be attested after successful security checks, and the data stored for audit purposes. Additional security checks can ensure the build server is not spoofed or compromised. 

3. Provenance Checks

This important security check can be applied to ensure configurations, files, code, and infrastructure are not intentionally or unintentionally altered from their ideal or desired state. Policy orchestration can be used to determine if there are any alterations, and subsequent policy violation notifications can be sent to specific stakeholders. For audit purposes, version control can be applied to all the assets, including code, configurations, manifests, etc., to track alterations, the resources or people who triggered them, and even the person who approved them manually.

4. Release Autonomy, Compliance and Governance

Many enterprises need visibility into what version of the software from what branch is being deployed and where it is getting deployed. Enterprises first need to obtain complete visibility and traceability into what is getting deployed, where then policy checks for compliance can be automatically applied to verify releases and deployments match what is expected.

5. Security Checks During Infrastructure Provisioning

It is important for enterprises to apply security checks as a part of the process of provisioning and configuring infrastructure, not as an afterthought when something goes wrong. For example, it is as important for a bank to deploy the right security checks while provisioning infrastructure for a net banking team as it is to provision the right infrastructure with the specified hardware configurations. These configurations can be tracked and version-controlled in a GIT. Common security checks include making sure the server has a private IP, encryption is enabled, and security scanning is enabled. In fact, the infra shouldn’t get provisioned if the security checks are not met. This can be done using custom stages within the workflow with a no-code, no-script approach, where all incidents and activities are automatically updated in the governance tools – for example, Jira or ServiceNow. 

6. Infrastructure Scanning

Multiple infrastructure scanning tools are currently being used by enterprises, but more important than the particular scanning tool is managing and acting upon the outcomes of the scanning jobs – kill the pipeline, notify stakeholders, identify and fix the issue, etc. — and automating the process in a repeatable manner. Enterprises can leverage third-party tools or native cloud capabilities available on GCP, AWS, or Azure, and a lot of automation can be applied there. The purpose of automation is to shrink the preparation time for production deployments and accelerate the delivery of the software (up to a 10x increase in some cases).

7. Security Guardrails and Pipeline Governance

Role-based access controls (RBAC) are mandatory for tight governance and insights into who is doing what, when, and where. It creates guardrails in the access and execution of activities and jobs within an end-to-end pipeline. When RBAC is combined with policy orchestration, enterprises are able to meet security and governance compliance requirements, for example, setting up separation of duties as a part of SOX implementation. Any policy violation will notify the respective teams, enabling them to decide the outcome of the stage (e.g., send it for manual review, kill the process, or proceed further if there is no violation).

8. Delivery Integrity and Attestation

This ensures that no compromised release gets onto the infrastructure, whether the infra is used for internal activities (build, artifacts — aquasec) or as a deployment destination. Besides this, enterprises may want to attest to the verification of infrastructure for compliance and auditing, which can be automated to eliminate any manual intervention.

9. Deployment Verification, Branch Verification, CVE Checks

Post-deployment, not just performance verification but also deployment security verification, should be automated with the help of custom stages to perform these checks. For example, you may want to ensure that only the intended code got deployed. Enterprises may also want to apply policy checks before any stage to verify the provenance of pipeline, code, and configurations while also checking on the person executing that activity (if it’s manually triggered). A check on branch and CVEs performed in an automated manner ensures that no vulnerabilities or compromises were introduced. This requires deep insights into your end-to-end pipeline and specific jobs within the workflow, as well as the ability to map a user within a group designated for a specific job. RBAC is ideal for enabling these guardrails. 

10. Audit and Traceability of the Delivery Chain

Enterprises collect data, logs, etc., to analyze and represent details around a sequence of activities that may have led to a particular incident. It is an extremely time-consuming manual activity. However, it need not be that painful. In fact, many enterprises are “audit ready.” With a press of a button, they know who did what, when, and where. They can also get into the specifics and perform a search on going from code to prod, going from pod in prod to CVEs, backward tracing, and audits around pipeline executions, deployments, policy violations, etc. All this can be visually represented on a dashboard with drill-down capabilities.

11. Secrets Management

It is essential to include a secrets management capability and not let credentials float within the code through your pipelines. This is another common cause of security breaches, and it typically happens when you have different teams responsible for different activities, which then get transitioned to other teams as part of a manual or disjointed workflow. With the transitions, secrets get exposed, creating a threat. Including a vault or any other secrets management tool and setting it up as an integral component of your software delivery supply chain and associated tools is extremely important. 

Conclusion

While no security implementation will ever be perfect, these 11 security checks can dramatically reduce risk in your software release and delivery processes, leading to reduced overall costs while protecting your organization from lost sales, reputational damage, frustrated users, and more.