DevSecOps

DevSecOps represents a natural and necessary evolution in the way development organizations approach security. In the past, security was 'tacked on' to software at the end of the development cycle (almost as an afterthought) by a separate security team and was tested by a separate quality assurance (QA) team.

This was manageable when software updates were released just once or twice a year. But as software developers adopted Agile and?DevOps?practices, aiming to reduce software development?cycles to weeks or even days, the traditional 'tacked-on' approach to security created an unacceptable bottleneck.

DevSecOps integrates application and infrastructure security seamlessly into Agile and DevOps processes and tools. It addresses security issues as they emerge, when they're easier, faster, and less expensive to fix (and before they are put into production). Additionally, DevSecOps makes application and infrastructure security a shared responsibility of development, security, and IT?operations teams, rather than the sole responsibility of a security silo. It enables “software, safer, sooner”—the DevSecOps motto–by automating the delivery of secure software without slowing the software development?cycle.

How Does DevSecOps Work?

The benefits of DevSecOps are simple: Enhanced automation throughout the software delivery pipeline eliminates mistakes and reduces attacks and downtime. For teams looking to integrate security into their DevOps framework, the process can be completed seamlessly using the right DevSecOps tools and processes.

Let's take a look at a typical DevOps and DevSecOps workflow:

• A developer creates code within a version control management system.
• The changes are committed to the version control management system.
• Another developer retrieves the code from the version control management system and carries out analysis of the static code to identify any security defects or bugs in code quality.
• An environment is then created, using an infrastructure-as-code tool, such as Chef. The application is deployed and security configurations are applied to the system.
• A test automation suite is then executed against the newly deployed application, including back-end, UI, integration, security tests and API.
• If the application passes these tests, it is deployed to a production environment.
• This new production environment is monitored continuously to identify any active security threats to the system.

With a test-driven development environment in place and automated testing and continuous integration part of the workflow, organizations can work seamlessly and quickly towards a shared goal of increased code quality and enhanced security and compliance.

BENEFITS OF THE DEVSECOPS MODEL

1. Faster delivery:?The speed of software delivery is improved when security is integrated in the pipeline. Bugs are identified and fixed before deployment, allowing developers to focus on shipping features.
2. Improved security posture:?Security is a feature from the design phase onwards. A shared responsibility model ensures security is tightly integrated—from building, deploying, to securing production workloads.
3. Reduced costs:?Identifying vulnerabilities and bugs before deploying results in an exponential reduction in risk and operational cost.
4. Enhancing the value of DevOps:?Improving overall security posture as a culture of shared responsibility is created by the integration of security practices into DevOps.
5. Improving security integration and pace:?Cost and time of secure software delivery is reduced through eliminating the need to retrofit security controls post development.
6. Enabling greater overall business success:?Greater trust in the security of developed software and embracing new technologies enables enhanced revenue growth and expanded business offerings.

Best practices for DevSecOps

DevSecOps should be the natural incorporation of security controls into your development, delivery, and operational processes.

Shift left

?

'Shift left' is a DevSecOps mantra: It encourages software engineers to move security from the right (end) to the left (beginning) of the DevOps (delivery) process. In a DevSecOps environment, security is an integral part of the development process from the beginning. An organization that uses DevSecOps brings in their cybersecurity architects and engineers as part of the development team. Their job is to ensure every component, and every configuration item in the stack is patched, configured securely, and documented.

Shifting left allows the DevSecOps team to identify security risks and exposures early and ensures that these security threats are addressed immediately. Not only is the development team thinking about building the product efficiently, but they are also implementing security as they build it.

Security education

?

Security is a combination of engineering and compliance. Organizations should form an alliance between the development engineers, operations teams, and compliance teams to ensure everyone in the organization understands the company's security posture and follows the same standards.

Everyone involved with the delivery process should be familiar with the basic principles of application security, the Open Web Application Security Project (OWASP) top 10, application security?testing, and other security engineering practices. Developers need to understand thread models, compliance checks, and have a working knowledge of how to measure risks, exposure, and implement security controls

Culture: Communication, people, processes, and technology

?

Good leadership fosters a good culture that promotes change within the organization. It is important and essential in DevSecOps to communicate the responsibilities of security of processes and product ownership. Only then can developers and engineers become process owners and take responsibility for their work.

DevSecOps operations teams should create a system that works for them, using the technologies and protocols that fit their team and the current project. By allowing the team to create the workflow environment that fits their needs, they become invested stakeholders in the outcome of the project.

Traceability, auditability, and visibility

?

Implementing traceability, auditability, and visibility in a DevSecOps process leads to deeper insight and a more secure environment:

• Traceability?allows you to track configuration items across the development cycle to where requirements are implemented in the code. This can play a crucial part in your organization’s control framework as it helps achieve compliance, reduce bugs, ensure secure code in application development, and help code maintainability.
• Auditability?is important for ensuring compliance with security controls. Technical, procedural, and administrative security controls need to be auditable, well-documented, and adhered to by all team members.
• Visibility?is a good management practice in general, but very important for a DevSecOps environment. This means the organization has a solid monitoring system in place to measure the heartbeat of the operation, send alerts, increase awareness of changes and cyberattacks as they occur, and provide accountability during the whole project lifecycle.

Which application security tools do you need to implement DevSecOps?

To implement DevSecOps, organizations should consider a variety of application security testing (AST) tools to integrate into their CI/CD process. Some commonly used AST tools follow:

• Static application security testing?(SAST)
• Software composition analysis?(SCA)
• Interactive application security testing?(IAST)
• Dynamic application security testing?(DAST)

SAST

SAST tools scan proprietary code, or custom code, for coding errors and design flaws that could lead to exploitable weaknesses.?SAST?tools are used primarily during the code, build, and development phases of the SDLC. Coverity is one such SAST tool.

SCA

SCA tools such as Black Duck scan source code and binaries to identify known vulnerabilities in open source and third-party components. They also provide insight into security and license risks to accelerate prioritization and remediation efforts. In addition, they can be integrated seamlessly into a CI/CD process to continuously detect new open source vulnerabilities, from build integration to pre-production release.

IAST

IAST tools, working in the background during manual or automated functional tests, analyze web application runtime behavior. For example, the Seeker?IAST?tool uses instrumentation to observe application request/response interactions, behavior, and dataflow. It detects runtime vulnerabilities and automatically replays and tests the findings, providing detailed insights to developers down to the line of code where they occur. This enables developers to focus their time and effort on critical vulnerabilities.

DAST

DAST is an automated black box testing technology that mimics how a hacker would interact with your web application or API. It tests applications over a network connection and by examining the client-side rendering of the application, much like a pen tester would.[5] DAST tools do not require access to your source code or customization to scan your stack. They interact with your website and find vulnerabilities with a low rate of false positives. For example, Synopsys?Web Scanner?and?Synopsys?API Scanner?DAST tools identify vulnerabilities on web applications and APIs, including web-connected devices such as mobile back-end servers, IoT devices, and any RESTful or GraphQL APIs.[6]