DevOps.com

  • Latest
    • Articles
    • Features
    • Most Read
    • News
    • News Releases
  • Topics
    • AI
    • Continuous Delivery
    • Continuous Testing
    • Cloud
    • Culture
    • DevSecOps
    • Enterprise DevOps
    • Leadership Suite
    • DevOps Practice
    • ROELBOB
    • DevOps Toolbox
    • IT as Code
  • Videos/Podcasts
    • DevOps Chats
    • DevOps Unbound
  • Webinars
    • Upcoming
    • On-Demand Webinars
  • Library
  • Events
    • Upcoming Events
    • On-Demand Events
  • Sponsored Communities
    • AWS Community Hub
    • CloudBees
    • IT as Code
    • Rocket on DevOps.com
    • Traceable on DevOps.com
    • Quali on DevOps.com
  • Related Sites
    • Techstrong Group
    • Container Journal
    • Security Boulevard
    • Techstrong Research
    • DevOps Chat
    • DevOps Dozen
    • DevOps TV
    • Digital Anarchist
  • Media Kit
  • About
  • AI
  • Cloud
  • Continuous Delivery
  • Continuous Testing
  • DevSecOps
  • Leadership Suite
  • Practices
  • ROELBOB
  • Low-Code/No-Code
  • IT as Code
  • More Topics
    • Application Performance Management/Monitoring
    • Culture
    • Enterprise DevOps

Home » Blogs » Enterprise DevOps » Rework is Choking Software

Rework is Choking Software

By: Derek E. Weeks on June 24, 2015 Leave a Comment

 

Recent Posts By Derek E. Weeks
  • State of the Software Supply Chain: Secure Coding Takes Spotlight
  • Reducing Risk in Applications Using Docker Containers
  • 200 Billion Downloads Can’t Be Wrong
More from Derek E. Weeks
Related Posts
  • Rework is Choking Software
  • Researchers Find Privilege Escalation Vulnerability in GitHub Repos
  • A True Story: DevOps(Sec) Manages Out Elective Risks
    Related Categories
  • Blogs
  • Enterprise DevOps
    Related Topics
  • continuous delivery
  • devops
  • DevOpsSec
  • opens source governance
  • rugged devops
  • Software Supply Chain
Show more
Show less

Rework is Hell

“Software may be eating the world, but rework is choking software”, tweeted John Jeremiah (@j_jeremiah).  To shed more light on what is choking software, new data was released last week in the 2015 State of the Software Supply Chain Report.

DevOps/Cloud-Native Live! Boston

In its discussion of application quality and integrity, the report revealed that the average application includes 106 open source components.  It is clear that the use of these components has benefited development tremendously in helping to speed time to market and improve innovation.  While the benefits are undeniable, development teams are also delivering applications that are “insecure by design”.  Of the 106 components per application, the report’s analysis revealed an average of 24 (i.e., 23%) have known critical or severe security vulnerabilities.  Those same apps also showed an average of 9 restrictive license types (e.g., GPL, AGPL, LGPL).

Screen Shot 2015-06-22 at 9.50.20 AM
By electively sourcing components with known vulnerabilities and potential license risks, software development teams are building up higher levels of technical and security debt. And in order to reduce some of that debt, unplanned and unscheduled rework is often required.

No Developer Intentionally Uses Bad Parts

I have never met a developer that intentionally wanted to use “bad” components in their applications.  That said, I have also never met a developer that wanted to spend four hours researching the latest versions, open source licenses and known security vulnerabilities for components (including dependencies) they wanted to use in their applications.  While 57% of development organizations have internal policies in place that direct “thou shall not use components with poor quality and integrity”, many have stated that the policies are not followed or are simply not enforced.
Screen Shot 2015-06-22 at 3.02.42 PM

The problem is one of volume and velocity, while people clutch to old processes that simply can’t keep pace.  The analysis in the 2015 State of the Software Supply Chain report revealed that billions of open source downloads occurred in 2014, of which 6.2% had known vulnerabilities (1 in 16 downloads).  For some large companies, the volume of downloads exceeded 240,000 — where 15,000 (7.5%) had known security vulnerabilities.  At these volumes, manual processes and paper-based policies to prevent poor quality or risky components from getting into your software have no possibility of keeping pace.  While software development practices aim for higher velocity, through component-based development as well as Agile, continuous and DevOps practices, the processes to keep up with it have not changed enough.

The only way to keep pace with this velocity is through automation.  And if we want to avoid unplanned rework associated with remediating known security vulnerabilities or selecting alternative components with approved license types, automation has to become the norm rather than the exception within development.

At Speed

“If I look at the mass, I will never act. If I look at the one, I will.” — Mother Teresa

Looking at the massive volume and velocity of open source and other artifact consumption can be discouraging and overwhelming. However, the volume and velocity within our software supply chains will not diminish—and without a new approach, the volume of unchecked quality and integrity of parts being consumed will continue to build up as technical debt.

Automation in areas of testing, build, and deployment has provided significant performance benefits. Likewise, investments in software supply chain automation have shown markedly improved efficiency and controlled risk, as the best practices in the 2015 Report illustrate.  Automation can unleash the potential of an organization’s development capacity. Rarely is there such an opportunity to simultaneously increase speed, efficiency, and quality.

In order to improve the quality and integrity of components used in our applications, we need to release our clutch on old practices.  We can further embrace automation across our software supply chains — and improve the quality of our applications — by considering these three steps:

1. Start with creating a software bill of materials for one application.  Visibility into one application can help you better understand your current component usage. A number of free and paid services are available to help you create a software bill of materials within a few minutes. The bill of materials will help you to identify the unique component parts used within your application and the suppliers who contributed them. These reports list all components used, and several services also identify component age, popularity, version numbers, licenses, and known vulnerabilities.

2. Design approval processes to be frictionless, scalable, and automated.  Manual reviews of components and suppliers cannot keep pace with the current volume and velocity of consumption. Your organization must not only define your policies for supplier and part selection but also find practical ways to enforce them without slowing down development or inadvertently encouraging workarounds. Policies must be agile enough to keep pace with modern development. Strive to automate policy enforcement and minimize drag on developers.

3. Enable developer decision support.  Developers are primary consumers of components in software supply chains. They initiate every component request. Help developers by automating the availability of information on component versions, age, popularity, licenses, and known vulnerabilities within their existing development tools so it is easy to pick the best components from the start. By selecting the highest-quality components from the highest-quality suppliers early, you will improve developer productivity and reduce costs.

Here is the complete 2015 State of the Software Supply Chain Report.  I will also be discussing more of the Report findings and best practices on a webinar scheduled for Wednesday, June 24, 12pm ET (register or view it on-demand).

The previous blog in this series was, Fewer and Better Suppliers.  Next up, I will be reviewing Visibility and Traceability practices across the software supply chain with more commentary from the 2015 State of the Software Supply Chain Report.

Filed Under: Blogs, Enterprise DevOps Tagged With: continuous delivery, devops, DevOpsSec, opens source governance, rugged devops, Software Supply Chain

Sponsored Content
Featured eBook
The 101 of Continuous Software Delivery

The 101 of Continuous Software Delivery

Now, more than ever, companies who rapidly react to changing market conditions and customer behavior will have a competitive edge.  Innovation-driven response is successful not only when a company has new ideas, but also when the software needed to implement them is delivered quickly. Companies who have weathered recent events ... Read More
« Bimodal IT and Remodeling Traditional IT for Greater Agility
How ITIL Can Co-Exist With DevOps »

TechStrong TV – Live

Click full-screen to enable volume control
Watch latest episodes and shows

Upcoming Webinars

Modernizing Jenkins Pipelines With CD Automation
Tuesday, May 17, 2022 - 11:00 am EDT
Applying the 2022 OSSRA Findings to Software Supply Chain Risk Management
Tuesday, May 17, 2022 - 1:00 pm EDT
Getting Mainframe and IBM i Data to Snowflake
Tuesday, May 17, 2022 - 3:00 pm EDT

Latest from DevOps.com

Why Over-Permissive CI/CD Pipelines are an Unnecessary Evil
May 16, 2022 | Vladi Sandler
Why Data Lineage Matters and Why it’s so Challenging
May 16, 2022 | Alex Morozov
15 Ways Software Becomes a Cyberthreat
May 13, 2022 | Anas Baig
Top 3 Requirements for Next-Gen ML Tools
May 13, 2022 | Jervis Hui
Progress Expands Scope of Compliance-as-Code Capabilities
May 12, 2022 | Mike Vizard

Get The Top Stories of the Week

  • View DevOps.com Privacy Policy
  • This field is for validation purposes and should be left unchanged.

Download Free eBook

Hybrid Cloud Security 101
New call-to-action

Most Read on DevOps.com

Agile/Scrum is a Failure – Here’s Why
May 10, 2022 | Richi Jennings
How Waterfall Methodologies Stifle Enterprise Agility
May 12, 2022 | Jordy Dekker
How to Secure CI/CD Pipelines With DevSecOps
May 11, 2022 | Ramiro Algozino
Update Those Ops Tools, Too
May 11, 2022 | Don Macvittie
Progress Expands Scope of Compliance-as-Code Capabilities
May 12, 2022 | Mike Vizard

On-Demand Webinars

DevOps.com Webinar ReplaysDevOps.com Webinar Replays
  • Home
  • About DevOps.com
  • Meet our Authors
  • Write for DevOps.com
  • Media Kit
  • Sponsor Info
  • Copyright
  • TOS
  • Privacy Policy

Powered by Techstrong Group, Inc.

© 2022 ·Techstrong Group, Inc.All rights reserved.