DevSecOps: A Prudent Programming Approach
In 2020, the price of running low-quality applications in the U.S. amounted to about $2 trillion.[1] Cybersecurity was among the issues responsible for the high cost. In this post, we’ll examine how software developers are addressing cybersecurity challenges.
Old days: Retrofitted security
In past times when the prospect of countless cyber threats seemed remote, software developers largely overlooked security or viewed it as an afterthought. It was common practice to retrofit security features to an app only after its creation. The “finished” software would be prone to a wide range of security issues.
The new DevOps beginning
As development teams adopted and realized the benefits of Agile they were often constrained by Operational and Infrastructure requirements. In 2010, a new approach appeared, known as DevOps, focusing on improved communication and collaboration between development and operations teams. A short time later, Forrester reported nearly half of the organizations were implementing DevOps. Today it rates among the most popular approaches to software development, offering automated processes, faster times to market and increased profitability.
Coincidentally, as DevOps won favor for advancing software development, computer users faced a world of increased cybersecurity risks. Developers took note and a new generation of DevOps would soon appear.
Security joins the DevOps team
Software developers augmented DevOps so that members of the security team would share equal status and control with development and operations teams. The resulting approach came to be known as DevSecOps.
Integrate security from inception to completion
Unlike most other development approaches, DevSecOps integrates security into an app during every phase of its development – from inception through completion. Each development stage is iterative:
- Establish a design and identify the security requirements for each feature in the design.
- Test and evaluate each design component under threat and attack conditions
- Libraries
- Code
- Infrastructure
- Packages
- Integrated system
- Acquire and apply knowledge from findings in step #2
- Repeat
By creating more robust, secure software, developers contribute to the security of an entire enterprise and all components within it.
DevSecOps components
Let’s move on to a brief survey of other DevSecOps components (most of which overlap with those of DevOps). They include:
- Infrastructure as code (IaC)
- Continuous integration/continuous deployment (CI/CD)
- Immutable infrastructure
- Automated builds
- Automated testing
- Static and dynamic code analysis
- Containers (Docker and Kubernetes), microservices, and serverless
Infrastructure as Code (IaC)
An essential to DevSecOps component, IaC enables management of infrastructure (such as networks and virtual machines) via machine-readable files, many of which are automated. In the past, managing infrastructure was a complicated operation that involved high numbers of personnel, large amounts of data storage and a fair likelihood of error. With IaC capabilities Developers can reliably deploy and test code on the infrastructure required for the application. Through IaC, developers gain a process that is significantly more secure, efficient and robust. IaC also enables app testing early in development cycles. In addition, validating and testing IaC can help avoid deployment issues.
Continuous integration/continuous deployment (CI/CD)
CI and CD are two more examples of enforced quality assurance. Whenever a code change occurs, CI and CD execute. CI is the process of testing every code base change — automatically and promptly after any alteration occurs. Following integration testing, CD directs any app changes to production or staging systems. (Also see “Automated testing” below.)
Immutable infrastructure
In an environment of immutable infrastructure, servers are never modified or repaired. DevSecOps promotes this idea for the sake of reliability and consistency. Instead, if a server requires updates, repair or modification, the updated and testing within the development lifecycle, using IaC, CI/CD and automation as much as possible. Only upon successful testing and validation are the updates automatically deployed into production. This process increases the Integrity and Availability of production systems.
Build automation
This process automates a software build and its related activities, such as code compilation, binary code packaging and automated test execution. Because they require little or no human intervention, automated builds save large amounts of time and expense as they reduce errors and promote efficiency. Automated builds can also determine if code works as intended.
Automated testing
Approaches to test automation can take several forms, the two most common being:
- API testing — Uses a programming interface to the software in order to confirm the activity being tested.
- GUI testing — Creates user interface actions (typically mousing or keystrokes) and notes changes that occur in the user interface. The purpose is to confirm the activity being tested.
Whatever the chosen approach, test automation yields several major benefits, particularly in an Agile setting. Some of them include:
- Speed — Test automation expedites development cycles and time to market.
- Economy — Automated testing results in reduced costs of projects and personnel.
- Accuracy — The uniform, automated execution of precisely the same test yields more accurate results than does manual testing by humans.
- Better apps — Developers can run hundreds or thousands of test cases concurrently, bringing an app to peak performance.
Static and dynamic code analysis
Static and dynamic code analyses are typically done as part of source code review.
- Static analysis occurs without code execution.
- Dynamic analysis occurs during code execution and focuses on code behavior.
Security issues
- Static analysis detects about 85 percent of code problems.
- Dynamic analysis can also reveal security issues precipitated by code interaction with other system elements, including servers, web services and some databases.
Containers (Docker and Kubernetes), Microservices, and Serverless Architecture
What’s in the container
A container holds a complete runtime environment, including app, dependencies and other required files. The upshot: Developers can use containers to make their apps run in nearly any environment or OS. A product of OS-level virtualization, each container takes relatively little memory, boots fast and communicates with other containers. FYI: Containers have been around more than a decade, as evidenced by 2008 Linux (LXC). They became increasingly popular and powerful over the past several years, particularly since the arrival of Docker in 2013.
Docker and Kubernetes
At first, they might sound like a law firm, but Docker and Kubernetes are specialized technologies with large roles in the container development revolution. At this writing, Docker is the most popular container platform. For long-term, multiple container management (also referred to as “orchestration”), most developers opt for the market leader, Kubernetes.
Microservices and heavy hitters
Agile and DevOps teams also embrace microservices, a software architecture that breaks down a large application into a series of tiny components. Each component is modular and tasked with a specific job. Compared to large, “monolithic” software, microservices are reusable, adaptable and easily deployed. The future looks especially bright for microservices, especially considering that its early adopters and proponents include mega IT forces such as Amazon, Coca Cola and Walmart.
Serverless
Serverless architecture (also called “function as a service” or FaaS) removes the software developer’s need for server software and hardware. Under FaaS, the developer transforms code into functions, each hosted by a FaaS vendor. The developer pays only for the use of individual functions — not for an entire application. Both Amazon and Microsoft number among the organizations offering support for serverless architecture.
Closing thoughts
That concludes our quick introduction to DevSecOps. In our next posting, we’ll look at Domain Driven Design.
SkyePoint designs cybersecurity applications, and our clients include the State Department, Department of Treasury, the Environmental Protection Agency and the Department of Defense, among others. We welcome the opportunity to work with you.
To learn more
Please reach out to us at bd@skyepoint.com for more information on our approach to Domain Driven Design or to discuss collaboration opportunities.
[1] January 7, 2021. Poor-quality software costs US trillions. Security Magazine. https://www.securitymagazine.com/articles/94289-poor-quality-software-costs-us-trillions