| 12 min read
Table of contents
The implementation of DevSecOps in your organization, in a nutshell, requires a radical transformation in the ways of thinking and acting concerning security and how it is integrated into the software development and delivery processes. Before going into detail about the principles, challenges and recommended techniques or practices for this implementation, let's briefly define the DevSecOps concept, about which we have already presented a more extensive introduction in a previous post.
What is the DevSecOps methodology?
When we talk about DevSecOps, we refer not only to a methodology but to an expanding culture among technology development companies where security is introduced and addressed from the beginning to remain throughout the software development lifecycle (SDLC). In DevSecOps, as part of an evolution of the prior model (DevOps), the security team is integrated into a collaboration between the development and operations teams. DevOps was focused on achieving a high speed of delivering an excellent quality product to the market. Now, DevSecOps retains that goal but adds the purpose of making sure that the product is secure. With this corporate culture, security becomes a shared responsibility of all organization members.
DevSecOps implementation overview
To implement DevSecOps is to shift security to the left. It is to integrate it into the technology development process before the first line of code appears. To adopt DevSecOps is to bring into the SDLC security requirements and tests, vulnerability prioritization and remediation, and judicious monitoring for risk prevention and cost savings. Unlike previous methodologies, the identification and remediation of security problems occur in time with the development activity, without waiting until the end of each cycle. In DevSecOps, security acts in the software planning, design, construction, testing and release, providing continuous feedback to all committed teams.
DevSecOps fundamental components
The implementation of DevSecOps is based on four fundamental components: people, processes, technologies and governance.
First, it is the people, i.e., the team members, who will be integrated to cooperate. They are who, as part of the cultural change, will assume shared responsibility for security in their workflows. They are who will train and be trained so that security is injected into the corporate DNA.
On the processes side, the shared responsibility model requires that the overall goals of software speed, security and stability are maintained by all stakeholders. Therefore, best practices in security, development and operations must be embraced from the outset and across the entire SDLC.
For the above, the support provided by technologies is crucial. These are integrated into the cycles and facilitate many processes. Security testing with automated tools, for instance, that complement manual security testing by experts, is valuable in the DevSecOps culture. However, automation must be used when necessary and not excessively so that it doesn't affect the effectiveness of software development and deployment.
Finally, DevSecOps must involve governance. Companies must monitor their procedures, measure their performance, identify and analyze their obstacles, failures and progress, define challenges and learn and improve with the help of feedback. The metrics obtained throughout an organization's DevSecOps maturation are pretty helpful for governance decision-making.
DevSecOps principles or basic steps
Relative to these elements, the following are some principles or basic steps in the implementation of DevSecOps within an organization:
-
Foster a gradual cultural change.
-
Educate, train and certify staff in various roles in security and best practices.
-
Choose at which points in the SDLC to carry out specific security procedures.
-
Automate processes (including some of the governance) and tools for stability and repetition in different phases of the cycles.
-
Start by evaluating small portions of code or specific, prioritized cases.
-
Conduct continuous manual interventions to retest and drill down.
-
Use metrics to measure performance and progress, and learn from feedback.
DevSecOps adoption drivers
The popularity of the DevOps methodology has been growing in recent years because of the agility it brings to software development and delivery. In the case of the DevSecOps methodology, its growing popularity is due to its clever —incredibly not yet seen as necessary by some— inclusion of security in the preceding approach without negatively affecting its efficiency. It was prudent to respond to the security issues emerging in the accelerated delivery of technology. Fortunately, an increasing number of organizations perceive security as a necessity in an environment plagued by unscrupulous people who wish to take advantage of human ignorance and errors by different methods and paths.
DevSecOps is attractive because it allows the constant prevention of risks and mitigation of threats that undoubtedly arise in software development. Also, because the early detection of vulnerabilities enables their remediation before going to production and at much lower costs. Thanks to the DevSecOps implementation, organizations can avoid bottlenecks with last-minute assessments and interrupting the rapid delivery of technology, which may even improve. In addition, they can promote transparency, build trust, maintain an excellent reputation and even increase their revenues with the help of a staff faithfully committed to security.
DevSecOps adoption challenges
Nevertheless, challenges can also arise for organizations to adopt the DevSecOps culture. One of the most commonly mentioned roadblocks is internal resistance to change. Realigning or redefining people's ingrained modi operandi and mindsets is often not a piece of cake. Development and operations teams may see the security team as a hindrance to the rapid delivery of results. They may have become accustomed to seeing it as a team with different priorities, previously working in a silo and even as an add-on in later stages of the SDLC, which should not disrupt their workflow. After all, they may believe that security is synonymous with slowdown, stagnation and even limitation of creativity.
Lack of knowledge about security and requirement compliance is also considered a challenge for DevSecOps implementation. It is common to find that developers lack security-related skills. Ridiculous ideas can even arise from misunderstanding the DevSecOps practice, such as that this method leads to a greater number of security issues. What people is failing to see clearly is that existing issues are identified and reported in organizations thanks to this method, something that doesn't normally happen with a simple DevOps methodology. Many want to ignore that they are at risk. They simply close their eyes until the impact wakes them up.
Another challenge in the implementation of DevSecOps is related to tools. Usually, DevOps tools such as those for CI/CD, source code management, code review, and build, among others, come from different vendors. Everything can be further complicated with the addition of security testing tools. With the absence of documentation and training, developers may find it challenging to choose among the available tools. Integrating the tools into DevOps pipelines can be complicated and time-consuming for them. Moreover, they may struggle to combine and reconcile results from diverse resources, especially if they are from different providers.
Obviously, monetary challenges can also arise. Changes in business practices can be costly. This is an impediment for many companies when the short and long terms are not evaluated. For example, training the team and acquiring tools can involve high costs in the short term. Still, a fast release of secure and high-quality products can generate profits in the long term, and the prevention of cyberattacks can avoid further elevated costs.
DevSecOps strategy: best implementation techniques
In accordance with the principles or basic steps mentioned above, we recommend the following practices for correctly implementing the DevSecOps culture in your organization.
-
Gradual cultural change: As mentioned above, change starts with people. The adoption of the DevSecOps culture can happen as it occurs with many other trends, that is, with a gradual chain effect. We do not recommend immediately promoting the methodology for all your organization's teams. You can start with small groups of individuals who have already shown a strong interest that fits the purposes of DevSecOps to incorporate this culture with new practices in their daily work. From there, the achieved benefits can serve as an inspiration to add more members of your organization to a successful turnaround. Of course, you must remember that this is not about giving birth to a new team called "DevSecOps." Team members in your organization will begin to transition to a mindset where everyone is responsible for security.
-
Security training and practice: Those who are already somewhat immersed in security theory and practice within your organization can serve as support to take the first steps in DevSecOps, possibly accompanied by external specialists in the field. With the latter, you can get security assessment services before starting development cycles. Together with your team, they can help you with threat modeling and defining which security controls and requirements to implement. But, with the help of the former, you should immediately start to face the challenge of lack of knowledge. So-called Security Champions, sometimes in the position of DevSecOps engineers, can establish knowledge-sharing plans and conduct formal in-house training to increase security awareness within each team. Through them and even online courses, your teams should receive training in best practices for secure coding and security issues handling and remediation. Naturally, they should witness and participate in the identification of vulnerabilities in your organization's products and in their remediation, receiving continuous feedback. To further develop their expertise and trust, they can also resort to earning certificates.
-
Choice of moments for security activities: Before thinking about what types of security activities to implement in your organization, it's prudent to reflect on the moments of the SDLC where they will be applied. By defining these points and through the discussion and analysis of security, it will be easier for you to choose the suitable activities and tools to implement. For example, considering the first phases of the DevOps pipeline, the above is more specifically directed to the initial planning process. In the coding phase, activities such as code review and security protocols for passwords and other sensitive information are often used. Then, in the building phase, having added code to the repository, static application security testing (SAST) and software composition analysis (SCA) can come into play. The former reviews code for vulnerabilities whereas the latter reviews code dependencies. In the testing phase, having a product ready to run and be tested, dynamic application security testing (DAST) can be used. This method does not access code but sends attack vectors to the endpoints of running applications. Penetration testing can be performed later in the DevSecOps lifecycle, in the releasing phase. This method relies on hackers who try to bypass controls, create custom exploits, etc.
(Image taken from here.)
-
Automation of security activities: To automate tools and processes related to security within the DevSecOps methodology is useful to avoid undermining the purpose of the DevOps approach of injecting speed. Process automation allows processes to take place consistently and iteratively. DevSecOps automation tools reduce burdens by delivering early warnings or relevant information to developers for quick remediation of security issues. However, it's important you determine how far automation should go because manual interventions are always necessary, for example penetration testing. Certainly, the manual effort remains an indispensable component for accuracy and depth.
Of note is that software and standards for its regulation are constantly changing. Therefore, automation for policy evaluation and compliance is quite helpful. Based on the industry your organization belongs to, your team selects security requirements they need or are required to comply with, e.g., PCI DSS, HIPAA, GDPR. Once the requirements are coded, automation allows you to quickly verify in the code or product if they are being violated and notify staff for prompt resolution. In addition, when you get compliance monitored and receive complete software statuses continuously, you can expedite response actions to avoid costly fines and regulatory lawsuits.
-
Incremental security assessment: In integrating and implementing security activities, it's wise to go slowly, without inordinate aspirations. To do otherwise, bombarding developers with a myriad of findings to tackle in short periods can lead them to feel reluctant to work on fixing them. So, instead of running full tests every time, a gradual assessment may be more reasonable, for example, in early cases, only attending to areas, or looking for vulnerabilities, of high priority. Later on, the following tests or security activities will serve as a complement for a broader and deeper assessment before going to production. Additionally, a significant recommendation for the sake of agility is that your organization's team of developers always submit code in small chunks for review.
-
Manual security activities: As previously stated, while automation is relevant in adopting DevSecOps, manual activity continues to be especially important. Automated vulnerability detection tools still report lies (false positives) and make omissions (false negatives). Manual assessments can do checks on this and more in-depth scans. For instance, the manual exercise can focus on tasks from the attackers' perspective to exploit vulnerabilities in a controlled manner and evaluate potential impacts on the organization (ethical hacking). The recommendation is that your organization have its systems assessed in continuous penetration tests that maintain a strong remediation culture. Just regular penetration tests are not recommended, since the period of time between one test and the other could give threat actors the chance to take advantage of your system's risk exposure.
-
Measuring performance and progress: Measurement is part of the proper implementation of DevSecOps. The ideal is to collect data from your organization on its performance within the new methodology, organize it carefully and establish meaningful metrics. Among the data to be captured may be, for example, those related to security tests and their findings, as well as remediation and deployment activities. Metrics allow keeping a record of progress. It is of great benefit to have a platform that eliminates noise in collecting data from different sources.
-
Learning by feedback: Measuring successes and failures will always be essential in DevSecOps adoption. But even more important is that those records serve to optimize processes within your organization. In continuous software integration and deployment, there will always be results to compare and analyze. The detection of what made things better or worse in a process or cycle is something you can transmit to your teams as feedback in the hope that it will lead to learning. The sooner you transmit it, the better.
-
New governance: Classic governance can mean delays in software delivery that in no way fit within the DevSecOps culture and mindset. The suggestion then is to turn again to automation. You can automate verification activities such as controls before the software is released to production. There is no need to manually assess a final security status; apply pre-selected exceptions and break the build when there are unfixed issues. To adopt new governance like this, within DevSecOps, you must have the collaboration and approval of your teams.
If you want to learn about DevSecOps best practices, i.e., the actions that keep your implementation alive, go to this post.
DevSecOps tools and resources
DevSecOps implementation includes tools for different security testing types integrated into the SDLC.
-
SAST: Tools for this type of testing scan code that is not running to detect coding and design errors that may create exploitable weaknesses.
-
SCA: Tools for this type of testing scan code and files of open-source and third-party components to identify known vulnerabilities and licensing issues.
-
DAST: Tools for this type of testing, which do not require access to source code, assess running applications to detect vulnerabilities related to their deployment configuration, data, and business logic.
Some recommended considerations for the selection of DevSecOps products include the following:
-
It is easy to install, configure and use.
-
It is highly accurate, i.e., generates low false positive and false negative rates, and looks for what you need it to look for.
-
It is fast enough to work within your SDLC.
-
It covers policies that your company needs to cover.
-
It can work continuously, in parallel and integrated with other tools in use.
Additionally, we would like to highlight a couple of resources related to the previous tools that are pretty useful in the implementation of DevSecOps:
-
Penetration testing: In this security testing methodology, in which the manual work of ethical hackers predominates over checks by automated tools, real attacks are simulated to identify vulnerabilities that threat actors in a given environment could exploit.
-
Attack resistance management platform: This is another type of tool that facilitates the management and remediation of security vulnerabilities. It consolidates data obtained by different methods and tools, makes it easier to understand and analyze the detected problems, and prioritizes the key findings for prompt remediation.
Learn here how Fluid Attacks uses DevSecOps tools.
Implement DevSecOps with Fluid Attacks
At Fluid Attacks, we're ready to help you in the transformation of your organization, implementing DevSecOps. We have certified and experienced security professionals in charge of integrating security processes and tools from the beginning and throughout your SDLC. In a single solution, we include automated tools for security testing such as SAST, DAST and SCA. Our ethical hacker team adds penetration testing or breach and attack simulation procedures and guarantees you low false positive and false negative rates. Further, our security tests can check around 50 international reference standards for your compliance requirements. All security vulnerabilities we detect in your software are reported in a single place: Fluid Attacks' platform. This platform lets you know the security status of your systems and apps, learn in detail about the vulnerabilities detected and prioritize them for prompt and correct remediation. Additionally, this platform allows you to track treatments and see metrics you can use to benchmark and make better decisions, among many other things. At Fluid Attacks, we hack your software constantly to stay one step ahead of malicious attackers. Furthermore, our DevSecOps solution makes security permeate your teams so that it is understood as everyone's responsibility.
Do you want to know more about DevSecOps?
For more information about Fluid Attacks' DevSecOps solution and how it can benefit your organization, follow this link or contact one of our experts. We also invite you to learn how our services are key to implement DevSecOps in AWS (here) and Azure (here). Additionally, here are two of our posts that answer the following DevSecOps questions: What is DevSecOps and what does a DevSecOps engineer do?
Table of contents
Share
Recommended blog posts
You might be interested in the following related posts.
