Implementing DevSecOps With 1,162 Apps

Stopping builds when a vulnerability is detected should be a basic component of CI/CD and DevSecOps. It helps ensure compliance, but it is also a major shift from how things are done now. Consequently, it can be a major source of frustration to developers. After all, all of their hard work is about to be unleashed in all of its glory to the world and the new system halts it in its tracks. It can be another source of frustration "brought on by security."

This is a reality of culture change and something that must be managed to be successful in implementing DevOps in an organization. Ramping up new processes and allowing team members to see the value to them and the organization as a whole facilitates a successful culture change.

After Hiep Tran's talk at the 2018 Nexus User Conference, I asked him if they implemented breaking builds for vulnerabilities all at once or phased it. He explained that it was incremental. Initially, developers received a warning to let them know about vulnerabilities and were allowed time to fix it. Eventually the policy was changed so that builds break if they contain a vulnerability.

Hiep works at Capital Group, where he is responsible for architecting, designing, and developing technical solutions to enhance the enterprise systems development life cycle (SDLC) on-premise or in the cloud with focus on automation and developer experience and efficiency. His talk laid out the Capital Group's utilization of the Nexus Platform, including the business use cases, their challenges, and implementation of Nexus Lifecycle into their DevSecOps CI/CD pipeline.

Prior to embracing DevSecOps, Capital Group saw the challenges they had and looked for solutions. Challenges such as:

• Only a hosted repository
• Manual upload of libraries
• No informed decisions
• No components scanning
• No metrics
• No monitoring

Requiring manual uploads to libraries through a ticketing system meant the "cost" to use it outweighed the risks it mitigated, so it was not being utilized. Developers were just working around the process - a common problem when you make it too burdensome. They also didn't have metrics or monitoring, meaning they didn't have informed decisions or component scanning. Clearly, all of these needed to be addressed, and they chose to implement DevSecOps and utilize Nexus Lifecycle as a tool.

Embracing DevSecOps is an investment, but an investment that pays off. Before starting down the path, Capital Group laid out their objectives to improve their organization:

• Vet all components
• Implement automated policy enforcement
• Shift informed decision making left (earlier in the development lifecycle)
• Use DevSecOps principles
• Measure and use metrics to improve code quality
• Utilize continuous monitoring to remediate vulnerabilities

Capital Group invested in Nexus Firewall and Nexus Lifecycle for automatic policy enforcement. Their developers use Nexus Lifecycle within their IDE to vet components they want to use. Now they can see right away which one to use and which one to lose. Nexus Firewall filters out bad components and, during automatic scanning, can block builds if there are policy violations, and create a Jira ticket to fix it through third-party implementations. They also use Nexus to report on the use of components throughout the enterprise and to allow for a proxy repository. According to Hiep, this all works together to allow them to bring products to market faster.

What is next for Hiep and the Capital Group team? They plan to improve their governance processes, utilize apps teams to increase the speed of remediations, and use Docker containers for the Nexus repositories.

Capital Group had over 1,000 build plans when they started this transformation. They were able to succeed, and you can too with planning, change management, and the right tools. To help you, watch Hiep's full talk here, for free, where he dives into more details on using Nexus Lifecycle for DevSecOps.

And, keep an eye out for more session recaps from the 2018 Nexus User Conference - we'll be sharing many of them leading up to this year's conference on June 12.