DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Deployment
  4. Implementing DevSecOps With 1,162 Apps

Implementing DevSecOps With 1,162 Apps

Stopping builds when a vulnerability is detected should be a basic component of CI/CD and DevSecOps.

Derek Weeks user avatar by
Derek Weeks
·
Apr. 30, 19 · Analysis
Like (2)
Save
Tweet
Share
6.11K Views

Join the DZone community and get the full member experience.

Join For Free

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.

app Nexus (standard) Continuous Integration/Deployment

Published at DZone with permission of Derek Weeks, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • The 31 Flavors of Data Lineage and Why Vanilla Doesn’t Cut It
  • Top Authentication Trends to Watch Out for in 2023
  • PHP vs React
  • RabbitMQ vs. Memphis.dev

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: