There are several key methods and techniques that can be used to incorporate DevSecOps into the SDLC. Less mature DevSecOps programs use a few; more mature DevSecOps programs use several.
Success Metrics
In DevSecOps, one size doesn't fit all. Standards and controls are built based on years of practical security experience at real organizations, but this is something that is constantly changing. Today, every DevSecOps practitioner needs to know how to optimize their unique program using data, metrics, and risk management objectives.
Like any business initiative, a DevSecOps program should have objectives and measurements to determine if those objectives are being met. An example of a risk management objective for DevSecOps: "Reduce the probability of attackers causing critical applications to stop functioning." A typical measurement that organizations use to help measure DevSecOps success is defect density, meaning the number of vulnerabilities divided by lines of code (lines of code are typically indicated by the 1000s).
A security metric often measures activities to provide decision support to perform functions better in the future. This data can help answer questions that an executive or operator might have about a particular area, such as source code review, using evidence-based information instead of opinion or anecdotes.
It's often said, "If you can't measure it, you can't manage it." It is indisputable that measuring results and performance is crucial to an organization's effectiveness, and this definitely applies to DevSecOps.
Defect Discovery and Testing
Penetration tests (also known as "pen tests") are a type of manual security testing that provides insight into an app's security by systematically reviewing its features and components. This type of exercise improves the security coverage of an app because the test is intended to explore the complete app rather than just focus on one type of vulnerability or one particular section. Pen tests follow methodologies related to topics like input validation, authentication, and access controls in order to identify flaws in the app's implementation.
Closed-box testers operate with limited knowledge and open-box testers utilize as much information as they can to inform their approach.
Pen Testing as a Service (PTaaS) provides on-demand manual penetration testing for web applications, mobile applications, and APIs. Findings are delivered through a platform that integrates with developer tracking systems like JIRA and GitHub. A SaaS platform also facilitates collaboration between pen testers, security team members, and development teams to not only find but also fix issues.
Security scanners can be programmed to identify certain kinds of vulnerabilities automatically. DevSecOps scanners come in two flavors:
- SAST scanners ("S" for "static" DevSecOps testing) examine the source code, binary, or byte code of an application.
- DAST scanners ("D" for "dynamic" DevSecOps testing) examine the application from the outside when it is running.
The most interesting and important security findings cannot be discovered via automated means alone. Human intelligence and creativity are necessary to discover security flaws in business logic. There are entire classes of security issues (authentication and session management) that cannot be discovered using automated tools.
Code review is the manual review of one developer's code by another developer. It's intended to find mistakes and improve code quality. Similarly, secure code review is a manual code review by a security expert. This is intended to find coding errors that may introduce security vulnerabilities. Secure code review is a manual process that often leverages SAST technology. Every so often, a security researcher not directly associated with an organization will discover and report a security vulnerability, which is called vulnerability disclosure.
A bug bounty is a type of vulnerability disclosure program that leverages a crowd of globally sourced researchers in competition. In a public bug bounty, anyone in the world can submit a potential security vulnerability to an organization, and the first to find a valid bug will be paid a "bounty."
Teamwork
Once you have performed security testing to find as many issues as possible, the next step — and by no means a trivial one — is to communicate issues to the development team. The development team is a critical stakeholder when it comes to prioritizing the fixes, remediating the issues, and ideally, preventing the same issues from coming up again.
One of the best ways to get security bugs fixed is to integrate with developer tools and processes. Now that you have your software inventory and identified security issues, you'll want to keep track of what has been tested, by what means, and when. Keep track of the findings from each security test and prioritize any necessary bug fixes or feature enhancements. In doing so, use business context to better understand which issues matter the most and work with development teams to fix those first.
Make sure you always know which issues are open and which have been addressed and can be closed. Then, report summary information to the relevant stakeholders so that everyone is always aware of the current status.
Proactive Techniques
The best DevSecOps training for developers is based on real security findings, whether these trainings are demonstrated during an actual security incident or found via manual penetration testing. The OWASP Top 10 contains a list of common DevSecOps risks; however, each organization will have its own unique top 10 list. Within your own organization, use this information to prevent entire categories of security vulnerabilities by implementing developer-focused training.
There are two common types of DevSecOps problems: bugs and flaws. Bugs are code-level mistakes, and flaws happen at the design level. Threat modeling is a type of design-level security assessment that is intended to examine the way an application system works to identify potential flaws. The process involves analyzing assets, security controls, and threat agents in the context of an application system. When flaws are detected using threat modeling before software implementation, some security problems can be avoided.
A few examples include:
- Cross-site request forgery tokens prevent cross-site request forgery attacks.
- A content security policy defines open-list assets that the browser allows to load and execute, thus minimizing the impact of cross-site scripting exploits.
- HTTP Strict Transport Security encrypts data in transit and prevents fallback to non-HTTPS traffic.
Other security issues can be avoided by securely configuring the software environment, for example, by following the Amazon CIS benchmark to harden AWS accounts and cloud services.
There are various tools meant to protect an application by identifying and stopping malicious activity while the application is running:
- Web application firewall (WAF) examines web traffic to identify and block suspicious activity, such as comment spam, XSS, and SQL injection attacks.
- Runtime application self-protection (RASP) operates in the runtime environment to monitor, detect, and alert in real time.
- Interactive application security testing (IAST) works inside an application, typically in a QA environment, to analyze code and report vulnerabilities.
Both WAF and RASP can be run in either "detect and alert" or "detect, alert, and block" mode. They are most effective at preventing security issues when running in "detect, alert, and block" mode. However, this forces the business to risk blocking legitimate application activity as well as malicious activity.
The "Three Ways" of Security
For decades, both software and security have struggled with poor quality results, cost overruns, and processes that require experts. While DevOps has shown promise on the software side, security is still practiced in very traditional ways. DevSecOps is not just shoving traditional security practices and tools into DevOps.
Instead, we must rethink the security work. We will need new practices and technologies to perform this work. We can give this transformation structure using the "Three Ways" from The Phoenix Project. By framing the problem this way, we can see that we need to:
- Get security work flowing – Most security work is monolithic and attempts to cover all risks in a single task, like a complete security architecture or security scan.
- Ensure instant security feedback – Security is one of the most common causes of technical debt, and the cost of this work increases dramatically the further it progresses across the SDLC. Several reasons include a lack of knowledge and limited security specialists.
- Create a security culture – Many organizations have a security culture of blind trust, blame, and hiding that prevents developers and operations from working with security.
Let's learn how to tackle the "Three Ways" of security:
- Get your security work flowing
- Make the work visible
- Work a single security challenge at a time
- Limit work in progress and reduce handoffs
- Automate everything
- Ensure instant security feedback
- Increase awareness about the importance of security
- Identify potential problems
- Make problems instantly visible
- Swarm on the problem and seek the cause
- Ensure security "findings" are designed for easy consumption
- Focus on providing a solution rather than exaggerating the problem
- Encourage a security culture
- Empower everyone to challenge security design and implementation
- Take every opportunity to make security threats, policies, architecture, and vulnerabilities visible
- Allow everyone on the team to participate in security
- Trust that engineering teams want to do the right thing
- Celebrate the knowledge gleaned from security issues rather than blaming those involved
- Spend more effort on upgrading practices and preventive measures than vulnerability remediation and incident response
- Plan trainings and conduct workshops to maintain continuous security throughout all teams
By following these core approaches, teams will see security as a concrete output from the development process. It is a combination of security features and assurance captured in a tangible way. By applying DevOps concepts, we can produce this concrete security continuously and effectively as a part of standard software development.
The "Five Ideals"
Six years after The Phoenix Project was released, The Unicorn Project was published in 2019. The Unicorn Project is not the sequel to The Phoenix Project. In fact, the stories of both novels take place along the same timeline and provide two different perspectives. The Phoenix Project introduces the "Three Ways" of security, whereas The Unicorn Project introduces "The Five Ideals."
Gene Kim, the author of both books, introduces "The Five Ideals" to frame today's modern business and engineering challenges. Let's further explore these five concepts:
- Locality and simplicity relates to the degree to which a development team can make local code changes in a single location without impacting various teams.
- We need to design things so that we have locality in our systems and the organizations that build them; we need simplicity in everything we do.
- The last place we want complexity is internally, whether it's in our code, organization, or processes.
- Focus, flow, and joy is all about how our daily work feels.
- Is our work marked by boredom and waiting for other people to get things done on our behalf?
- Do we blindly work on small pieces of the whole, only seeing the outcomes of our work during deployment when everything blows up, leading to firefighting, punishment, and burnout? Or do we work in small batches, ideally single-piece flow, getting fast and continual feedback on our work?
- These are the conditions that allow for focus and flow, challenge, learning, discovery, mastering our domain, and even joy. This is what being a developer means.
- Improvement of daily work addresses paying down technical debt and improving architecture.
- When technical debt is treated as a priority and paid down, and architecture is continuously improved and modernized, teams can work with flow, delivering better value sooner, safer, and happier.
- The business ultimately wins when developers can deliver on enterprise performance goals.
- Psychological safety is one of the top predictors of team performance.
- When team members feel safe to talk about problems, problems can not only be fixed but also prevented. Solving problems requires honesty, and honesty requires an absence of fear.
- In knowledge work, psychological safety should be treated with the same importance as physical safety is in manufacturing.
- Customer focus relates to the difference between core and context as defined by Geoffrey Moore.
- Core is what customers are willing and able to pay for, the bread and butter of your business, while context is what they don't care about and what it took to get them that product, including all of an organization's back-end systems (e.g., HR, marketing, development).
- It's critical to look at these context systems as essential, as mission-critical, and fund them appropriately. Context should never kill core.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}