Editor’s Note: This is a guest blog post from WhiteSource Software.
Jenkins has served as one of the accelerators of the DevOps movement over the past decade, making it easier for organizations to adopt the continuous integration and continuous delivery/deployment (CI/CD) technology that is at the core of the DevOps model.
CI/CD has grown in popularity, since it enables organizations to ship quality products frequently and predictably. However, there has been universal recognition that this automated process needs to be bolstered to detect security vulnerabilities in the code.
The question for many organizations that have moved to DevOps is how to ensure the security of their code without losing the speed advantage they gained from the new automation.
Making the move to DevSecOps can sound challenging for organizations, but it is a necessary step to remain competitive as the demand for better security standards grows throughout the industry.
Looking at the field, there appears to be two main challenges facing organizations. The first is in the tools used to build their products, while the second is more of a cultural gap.
Lack of standardization for security tools in DevOps land
CI/CD tools like Jenkins orchestrate the build, configure, deployment, testing and reporting of your code. The problem, especially if we are looking for more ways to automate the process of securing code without hindering its release, is the lack of a standardized security model to ensure that your code is protected.
For many organizations at this point, there might be a security layer at the stage before the code reaches the build, which can help catch issues early. When it comes to Jenkins users, there are plenty of fine third-party tools and plugins that can provide security at various stages, but very few run throughout. However, as a part of following a secure SDLC model, you want to make sure that you are implementing security checks at all stages of the process. These security tests should be carried out post-release as well, taking into account the fact that new vulnerabilities can always be found after your product is in the wild, facing new threats as hackers become aware of new exploits in the open source components that you are using in your product.
When a new vulnerability is discovered by security researchers and posted to one of the many databases and advisories that are available to the community, hackers can seize upon a single now known vulnerability to carry out multiple attacks. This is because popular open source components, which are reusable code, are being used in thousands of products, providing ample opportunities for hackers to make out with an easy payday based on publicly available information.
It’s necessary to define a model that the organizations can adopt to implement DevSecOps. For example, organizations should implement:
- Static Analysis Security Testing (SAST). Static analysis can detect security vulnerabilities without running the code and hence is an inexpensive and fast check.
- Dynamic Analysis Security Testing (DAST). Unlike SAST, dynamic analysis needs the code deployed and executed. This is crucial since these use cases are closer to how attackers penetrate our code.
- Software Composition Analysis (SCA). These tools detect the open source components in your software automatically and alert on security and compliance issues.
- Container security. Containers are prevalent these days and need to be as secure as the code that’s running inside the container.
Popular tools for SAST include Coverity and for DAST include OWASP ZAP. Both can be integrated with Jenkins, thus elevating the confidence of shipping code through Jenkins pipelines. Both Jenkins and Jenkins X empower users to control by choosing security tools they trust.
The use of CloudBees Core, an enterprise version of Jenkins, is critical for implementing your security policies and governance at scale. By providing enterprise management of security across your teams and projects, you can implement Role-Based Access Control (RBAC) across teams, manage security tools, allow approved pipeline integrations and enforce secure best practices.
For those working in more sensitive industries that require them to comply with regulations such as HIPAA, or one of the many financial standards, there may already be a set of approved tools. Bringing everyone onto the same page can be a challenge, and this is all before bringing the human element into the picture.
Taking on the friction between development and ops
Throughout a wide range of companies, we are seeing friction between the developers, security and ops professionals that is easy to understand but hard to resolve.
Even organizations that have been successful in adopting the right tools to make the transition to DevSecOps can face challenges when it comes to getting development, security and ops to collaborate.
While no developer wants to release code that contains known vulnerabilities that can be exploited, security isn’t a top priority for them. They are well-intentioned but can be misguided by stringent deadlines. Security is everyone’s job, just like quality. However, to improve accountability, security teams are constructed whose sole priority is to keep the product and business safe. If that means missing a release deadline, then so be it.
One school of thought is that this healthy tension pushes both sides to do their best to put out a product that is secure and high quality. Another school of thought is that this aggravates the silo behavior by creating two departments. There are a couple of basic ideas that can be tried out to bridge this “cultural gap.”
Like in any diplomatic struggle, ambassadors who spend time getting to know their “adversary” can help to establish better communication between the two sides. We are now seeing cases where in some organizations, they are doing cultural exchanges by adding developers to the security team and vice versa. The hope is that by getting to see how things look from the other side, they will begin to appreciate each other’s concerns and will develop processes that make the DevSecOps a reality. So far, the responses to this approach have been generally positive.
Small steps that make a big difference
Ideally, we may see the emergence of a true DevSecOps professional — perhaps we will grow them in a lab if it is faster — but this evolution, like the one before it, will probably take time.
Until then, our best option is likely to come from adopting better automated tools which perform the necessary security checks at all stages of the SDLC and making a good faith effort to build shared understanding across teams.
Visiting DevOps World | Jenkins World in San Francisco and want to learn more about how to implement DevSecOps more efficiently? Stop by to visit WhiteSource Security in booth #122, and listen to their 15-minute solution session in the Sponsor Theater. Use their discount code, JWWHISOUCUST, for 20% off your pass.