News about security breaches are frequent, and there are usually mistakes and negligence behind many cases. You would think that software engineers are the ones who care most about secure coding. But do they? Honestly, it’s not their primary duty.
Most software developers focus on building products based on requirements, equipping them with the necessary functions, and making them user-friendly. More diligent and experienced engineers will incorporate basic security checks. But, with today’s hackers, “basic” is no longer enough. That’s why we’ll be talking about DevSecOps – security incorporated into the code and carried throughout the entire integration and delivery processes. So, what is DevSecOps, and why should you care?
Table of Contents
IBM states that the average total cost of a security breach is $3.92 million, with the healthcare industry having the most expensive data leakages. The number of mobile apps, embedded devices, and IoT makes secure coding even more critical.
But, you can’t install an armored door on a cardboard house and hope you’re protected. You should start caring about security as soon as you draw up your house plan. DevSecOps is the methodology to use here. Security as code implies you have predefined security policies that are codified from the beginning of the project and can be repeated and used consistently.
If we just spell it out, the abbreviation stands for development, security, and operations. DevSecOps means the integrity of all three components where security is not solely the responsibility of a security team but a natural complement to every stage of the development lifecycle. It is not only about protection but also about compliance: industries like banking, healthcare, automotive, and more may have specific requirements to code repositories, deployment tools, etc.
Integrating security features once the app is ready for release doesn’t work well with continuous integration and delivery – standard practice these days. With short development cycles, the security as code culture must be built into every level of the DevOps process without influencing the time and cost of development.
On this level, DevSecOps presupposes building operational and compliance frameworks. Creating understandable metrics to evaluate results is vital as well. Monitoring should be available to all team members.
No division between development and security teams: cybersecurity experts should be a part of the development and operations teams from the beginning. They must work in synchronization, researching and tracking possible exploits, and fixing them along the development process.
The company’s responsibility is to ensure the integrated workflow with security automation tools, security telemetry, incident response, integrated backlog, and pipeline. To guarantee compliance and reveal security flaws early on, automated audit evidence collection should be a part of software development.
Security control has to be embedded early in the infrastructure and processes. It starts from the integrated development environment with specific security features and ends with recurring tasks automation.
Essentially, DevSecOps is a philosophy that ensures security as code culture and integrates security into all DevOps processes. At Relevant Software, we follow this philosophy by tracking changes to the infrastructure and code and identifying places where we can add security tests and checks when building products for our clients. The automation of gates and agreement upon an integrated development environment, with specific security features, are vital as well.
Since most software development companies have turned to agile methodologies, DevOps, with its priority on delivery time, has become a common practice. Via continuous integration, automation, communication, and collaboration, teams gain control over production, and reduce the time to market.
By adding a security component to this combination, companies increase the level of protection at all stages of the pipeline. As a result, with DevSecOps, we prioritize fast development of a secure codebase.
When it comes to continuous processes and automation, both DevOps and DevSecOps have similar methodologies, but the latter shifts the focus on security to the earlier stages. Continuous processes in DevSecOps include a feedback loop where software is continually monitored for threats, and all teams dynamically work on improvements.
As for the automation aspect of DevOps, it is also vital for the security component: it’s applied to compliance monitoring, code review, threat detection, and more. Speaking figuratively, DevSecOps is DevOps in an armored suit, with all team members working together to build it from scratch.
Establishing security protocols as the primary ingredient of the development lifecycle allows teams to write secure code from the start instead of adding the security “frosting” at the end. By integrating security early on, companies can:
While no one can guarantee 100% security of a project, companies should try and take into account as many risks as possible by following the best practices of the DevSecOps methodology. It’s never too early in the SDLC to start implementing the security as code culture.
Let’s move from the theoretical description of what DevSecOps is to its practical implementation into SDLC. Basically, the task is to ensure that security experts understand how developers work and help them build the necessary control into SDLC.
“Security as code is really about making security more transparent, to work with developers, and speak the same language. We really need to give them the tools and the security policies so they know what to do and can do it themselves.”Francois Raynaud, founder, DevSecCon
So, how do you implement DevSecOps?
Let’s dig even deeper into the SDLC stages to understand what security checks are needed and where they should be added along the way.
Before any software changes are added to the repository, additional security checks should be introduced at this stage:
It’s best to look at the design from the attacker’s perspective, searching for any gaps or vulnerabilities. For this, we suggest using an automated risk questionnaire, similar to what PayPal teams use. The initial point of assessment is whether you use existing languages and frameworks, or experiment with new tech and tools. For code review, it’s ideal to leverage tools like Gerrit, Phabricator, or Atlassian Crucible.
On the commit stage, you have to build and perform basic testing to determine whether the changes you introduced have broken the entire system or not. What should be included at this stage?
You most certainly use open source code, and it has to be reviewed with no exceptions – around 50 new critical vulnerabilities are reported every day in open-source software. To review your code automatically, you can use SCA tools from OWASP, Veracode, or Sonatype. These tools can be wired into your pipelines. For Docker containers scanning, use tools like OpenSCAP or solutions from Twistlock, FlawCheck, etc.
The next level is triggered by the success of the previous commit stage. In this area, security control includes:
Don’t forget to tune DAST tools to minimize false positives and remove duplicate findings after the scan (use Code Dx or ThreadFix for this). We recommend running a dynamic scanning in parallel with other tests, or complete it out of band to save time.
As for the functional and integration testing, developers must focus on misuse cases and “abuser” stories, i.e., write negative tests, which prove that unauthorized users cannot abuse certain features, access admin functions, tamper with data, etc. It is also wise to use manual penetration testing to validate your security program and satisfy compliance requirements. Bug bounties are common among top tech companies like Google, PayPal, or Netflix, so why not follow their example?
If the change you’re introducing to your system passes all the previous checks and tests, it’s ready for production deployment. Here, we implement the following security checks:
With the help of tools like Puppet, Chef, and Ansible, you can set up standardized configurations across multiple servers, minimizing the differences between production, test, and development environments.
These code-driven configuration management tools also automatically audit runtime configurations, issue alerts when something is missing, and can correct the problem. Cloud security protection solutions like Alert Logic, CloudPassage Halo, Illumio, Threat Stack, and others, offer Chef and Puppet integration.
Runtime Application Security Protection (RASP) is another runtime protection technology, with tools like Immunio, Waratek, Prevoty, and Contrast Security. There are also innovative approaches to runtime defense – tCell and Twistlock.
You may find interesting how to hire a Site Reliability engineer.
The security as code culture is at the core of our software development routine. For example, we have been creating software for FirstHomeCoach – a UK-based fintech company that required advanced protection for customers’ sensitive data. User data, gathered by the system, had to be secured with the help of a security-driven architecture and data segregation. DevSecOps was the best methodology to use for this scenario.
Along with server-side development, the Relevant team took the following security measures:
See our guide on how to hire a dedicated DevOps engineer.
Considering our experience in DevSecOps, we can define the top factors that influence this methodology’s outcome:
Relevant has the expertise, well-set processes, and tools to leverage the security as code culture. We can help startups stand against cyberattacks, prevent data leaks in cloud platforms, secure apps from penetration, and access a project’s level of vulnerability.
Our cybersecurity expertise allows us to provide our customers with security in development, deployment, production, and the cloud. So, if you need help implementing DevSecOps, feel free to request Relevant’s consultation or our services.