Will Quick and Security Ever Meet in DevOps?
Through the lens of data presented by the 2019 State of DevOps report, this article analyzes the relationship between speed, security, and DevOps.
Join the DZone community and get the full member experience.Join For Free
The adoption of DevOps by global enterprises has spiked in the last three years. While many companies have shown success by delivering software at break-neck speed, maintaining new security as per industry standards has been a pressing concern for all of them.
But why is this the case?
Traditionally in the waterfall model, security activities of a new software were started just before/after the day of deployment. There was no problem in this process because the delivery cycle itself was a quarter-long activity. But with DevOps, when the lead time is reduced to days, and delivery throughput has increased (at least 10-100 deployment per day), security and compliance teams find it hard to keep up with the pace.
There are two outcomes:
- The pace of delivery can slow down due to the inability of the Security team to walk with the same velocity
- Security standards can be given the cold shoulder to deliver critical business features
- Both the compromising cases are detrimental to any organization, although unequivocally, businesses prefer the second option with attached security risks.
- Why can't organizations transfer the idea from “Security or Delivery” to “Security and Delivery”?
Security is essential but not a priority: Software features are seen as a competitive differentiator among enterprises. Security is seen just as a guardrail or as a practice, and usually takes a long time to accomplish, hence is not prioritized.
Time to market is a priority: With increasing pressure to deploy new features to unlock new business opportunities, it is natural to incur risks and implement the feature with non-crippling bugs.
Everyone forgets: (this is my favorite) During my development days, there were few instances when I wrote a code that fulfilled just an immediate requirement but with a fair chance to mushroom new functional issues. Those codes were shipped to production with a thought that defects will be fixed later. Unfortunately, everyone forgot and resulted in technical debt.
Less guidance: There are a few vendors in the market who offer expertise and solutions on secured and continuous delivery.
The Emergence of DevSecOps
The DevOps process runs like a high-speed engine, and stopping it again and again for security checks is ineffective. Thus it is sensible to embed security into DevOps processes and ensure the software is safe and secure in real-time. This idea is called DevSecOps.
DevSecOps can assure organizations that the shipment of their software and services to production are trusted. The practice can ensure the security of applications and infrastructure from the beginning and avoid DevOps workflow from slowing down by using automation.
Let us understand the security types and how they can be integrated into DevOps.
There are three types of security concerns (as defined in State of DevOps report 2019): Vulnerability Risks Avoidance, Policy Controls& Countermeasures, and Audit and Traceability. They play a significant role in zeroing down the business risks during the software delivery runtime.
Three types of security concerns, as mentioned in the State of DevOps report, are:
- Vulnerability Risk Avoidance:
- Definition: Risk can be defined as any threat which can exploit CD system vulnerabilities to perform unauthorized and unacceptable actions, thereby causing harm to the organization.
- Solution: A CD solution should offer different ways to authorize and authenticate users.
- Authorization: CD Solution must provide privileged access to different users (Dev/Ops/InfoSec) based on their role by using existing frameworks such as LDAP/SAML or GitHub Team.
- Authentication: A team dealing with deployments of software into multiple applications and complex micro-services always needs a CD solution to authorize users. One of the ways is by storing passwords, tokens, and other secret information in security management systems (like Vault) or identity providers (like Google Teams) to avoid unauthorized transactions.
Policy control and Countermeasures:
- Definition: Baseline.org explains "Policy" as an action plan that is carried out to prevent any threat which can compromise the integrity and availability of IT. An example of such an action is to create policies to ensure an enterprise is compliant with industry standards and overall governance in an organization. Policy managers create policy plans (sort of tactics to IT governance) around the software delivery process, communicate and educate the DevOps team to adhere to those plans, and finally (dis)approve a deployment based on the group's adherence. All those activities are operated manually using documents and repeated whenever a change occurs.
Solution: Now, if governance has to be applied in DevOps, there must be auto-checks or auto-validations (also referred to as Controls) enforced into CI/CD pipeline. The results of these controls need to be recorded for verification and attestation by authorized and privileged users. The table below is a simple example of automatic controls enforced into the Source Code repository and Build-stage of the CI pipeline.
|Source Code repository||Peer review, unit tests are done. There is no sensitive information found during the scan. This activity can be promoted to the next stage, i.e., Build|
|Build||The accurate build configuration is achieved, and all downloaded dependencies are approved. This activity can be promoted to the next stage, i.e., Test|
Similarly, the below picture shows detailed lists of controls a policy manager would typically make in the non-prod and prod deployment stage to ensure secured and risk-free deployments. Fig. B:
So the idea here is, as delivery velocity dramatically increases, the
policies must be enforced into the delivery pipeline in the runtime. Instead of the tedious process of manually stopping an automated DevOps process to collect the data for security and governance validation, it can be automated through integrating policy engines like Servicenow, Sonarcube, etc..to your CD solutions.
Audit and Traceability:
- Definition: According to TechTarget, an audit is a comprehensive review of an organization's adherence to regulatory guidelines or specifications created by standard bodies like SOX, HIPAA, PCI DSS, FISMA. Audit reports verify if the compliance preparation, policy adherence, risk management training, access controls are in place.
- Solution: Firms with the highest level of security integration to their software delivery find auditing to be effective in identifying and mitigating their business-risk a lot compared to the ones with minimal or no integration. Below is the survey that represents the percentage of respondents (~3,000 participants from the IT and Development department) agreeing or disagreeing to audit is an important feature to identify and mitigate business risks. Note, the majority of respondents agree audit being crucial for identifying and minimizing security risks in an organization.
- With deeper integration of security into Software delivery, there will be more data around deployment; Auditors can watch those data for more audit findings, i.e. more things to fix. Hence enterprises need to have a CD solution with a dashboard providing information around software deliveries, which can periodically provide the evidence required by internal/external auditors. For e.g. the list of deployments into Kubernetes failed or terminated due to unauthorized execution of CI/CD Pipelines.
- Recently OpsMx, a leading provider of Continuous Delivery solution, released the Compliance and Audit feature in OpsMx Enterprise for Spinnaker OES. The compliance and audit feature provides all pieces of evidence around software delivery preventing auditors from manually ransacking pipeline data from the various systems to figure out adherence.
Achieving security while shipping code faster is not difficult, but every organization must seek the ultimatum. According to the state of DevOps report, it’s not accidental that organizations at the highest levels of DevOps evolution also have fully integrated security practices into their build, test, deploy, and release processes. With the highest level, they mean resources are available via self-service and automation, and data emitted from each stage of CI/CD is used for running the overall software delivery and maintaining security with high efficiency and precision. Attaining the highest level requires the two most important aspects:
Discipline to embed the siloed security groups into DevOps and form a collaborative mindset.
Opinions expressed by DZone contributors are their own.