staging-devopsy.kinsta.cloud

Tag: DevOpsSec

  • Getting Ready for All Day DevOps

    Getting Ready for All Day DevOps

    DevOps Practitioners Unite

    On Nov. 15, we’ll be broadcasting 54 live sessions across 15 hours and 15 time zones. The All Day DevOps conference will be live, online and free. Anyone who registers can watch.

    We have invited some top-notch practitioners from around the world to speak at the event on topics ranging from DevOps transformations, to CI/CD, to automated security, to modern infrastructure (think serverless, microservices and containers). The speaker lineup will include:

     

    www.alldaystaging-devopsy.kinsta.cloud

    Don’t Watch Alone – Host a Viewing Party!

    One of the best parts of attending a DevOps conference is getting to interact with others in the community. We have had many organizations including Capital One, Intuit and Fannie Mae approach us about hosting viewing parties at their offices—and opening the party to the public. Sound intriguing? Here’s how to do it:

    Secure the location. Pick your corporate auditorium, cafeteria or open meeting space. Secure it all day for Nov. 15. Make sure you have at least one internet-accessible viewing screen.

    Promote the session: One you have the approved locations and times, share them here with the All Day DevOps Conference organizers. We will help you promote your party on AllDaystaging-devopsy.kinsta.cloud and through social media postings, directing them to your registration page.

    Invite People to Register: Set up a place for people to register for your location. You’ll want to know how many people to expect because you need to know how much pizza to order. Meetup.com and Eventbrite.com make event registration easy.

    Make it Fun. Order some pizza and drinks. We’ll send along some cool laptop stickers from the conference and some of the sponsors. Share pictures from the event online (@AllDayDevOps). Join the conversation in the conference Slack channels. Set up birds-of-a-feather stations. Play some music during breaks. Set up viewing screens for each of the conferences three tracks.

     

    Just to be clear: the All Day DevOps Conference is not a collection of vendor pitches.  In fact, we have tried our darnedest to ensure the agenda is purely focused on real DevOps practitioners sharing their craft.  Take a moment to look at the speakers participating in each of the tracks and you’ll see what we mean.

    Register today. Invite your colleagues to attend.  Then plan a viewing party at your office.

    — Derek E. Weeks

  • All Day DevOps: Bringing DevOps to the World

    All Day DevOps: Bringing DevOps to the World

    An Audacious Plan: Deliver DevOps to everyone.

    The global audience for DevOps is expanding faster than any one person or company can keep up with. While DevOps Days and other regional events provide invaluable support to their local communities, we wanted to create a global event, offering the very best lineup of speakers across North America, Europe and Asia.

    We also wanted to make sure that anyone, anywhere can attend. So, we set a high bar for our organizing team, and they delivered: $0 registration.

    By creating All Day DevOps as an online event, we are able to get many people to attend and present—many of whom ordinarily would not be available because of time or travel restrictions. We expect well over 1,000 people to attend throughout the day.

    15 Time Zones, 15 Hours, 3 Keynotes, 54 Sessions

    Nov. 15 will see the first truly global, online DevOps Conference: All Day DevOps. Starting at 9 a.m. Greenwich Mean Time/5 a.m. Eastern Standard Time and continuing through midnight GMT/8 p.m. EST, there will be three simultaneous tracks, each track containing 18, 30-minute presentations, for a total of 27 hours of presentations.

    Call for Papers

    We are inviting speakers from around the world to participate in this first-of-its-kind event covering 15 time zones. Timing for the conference is set for the EMEA sessions to begin at 9 a.m. GMT, then, at 9:30 a.m. EST, move the concentration of presentations to the east coast of the United States and ending with presentations on the west coast of the United States starting at 11 a.m. PST. All sessions will be recorded, but you will need to register for the event to have access to the recordings.

    The Call for Papers is now live. Please submit your paper soon. The deadline for submissions is Sept. 21.

    Conference Tracks

    The conference will host three tracks: Modern Infrastructure, Automated Security and CI/CD. We’ll have 54 sessions plus three keynotes on three tracks, running continuously for 15 hours.

    Track One: Modern Infrastructure

    Modern Infrastructure Track Hosts and Moderators: James Wickett, Signal Sciences, joined by Ernest Mueller, AlienVault and Karthik Gaekwad, Oracle

    In this track, we will be discussing novel architectures, approaches and tools for building out software and services. We are not looking for the standard approaches, but the way Infrastructure will be in the next three to five years.

    Track Two: DevSecOps & Automated Security — Living the Dream

    Automated Security Track Hosts and Moderators: Milton Smith, Oracle, and Shannon Lietz, Intuit

    You have a well-tuned development and delivery environment or you’re in the process of building one. AppSec is a top business concern. You moved DevSecOps from Big Foot and UFOs to reality, you sold the dream to staff, and now it’s beginning to pay off. This track explores DevSecOps tools and techniques to build a successful automated security program.

    Track Three: CI/CD — Continuous Everything

    CI/CD Track Hosts and Moderators: Derek Weeks, Sonatype, and Andi Mann, Splunk

    Continuous delivery is not magic, but it does take the right effort. The most successful practitioners have taken pragmatic steps to reduce cycle times, improve collaboration and build quality in without burning people out. This track asks you to share your frontline experiences of building CI/CD pipelines, aligning key stakeholders and measuring the results. Remember, what’s now an everyday experience for you is awesome to another pursuing that path.

    Conference FAQs

    How to I register to attend?

    Registration is open now at AllDaystaging-devopsy.kinsta.cloud. The site will be constantly updated, sometimes multiple times per day, with the latest information. You can also follow us on Twitter under the handle @AllDayDevOps and using #AllDayDevOps.

    screen-shot-2016-09-12-at-4-44-16-pm

    How will the sessions be delivered?

    The sessions are delivered over Google Hangouts, allowing us to have an unlimited number of attendees on each of the three channels. All you need to deliver a presentation is a reliable internet connection.

    We are also arranging Slack channels for all sessions to host interactive Q&A sessions for everyone.

    If my talk is selected, can I post a notice or an article about the conference on my site?

    Not only is it OK, we would thank you profusely if you did. You’re welcome to use the banner and the conference icon if you need graphics for the article. Let us know when it goes up and we’ll give you a shout-out.

    Who is organizing All Day DevOps?

    The All Day DevOps Conference is organized by advocates in the DevOps community. We are working together to deliver a diversity of vendor-neutral sessions and speakers from around the globe to show practical usage and technical solutions of DevOps in small and large enterprises.

    • James Wickett, Signal Sciences
    • Derek Weeks, Sonatype
    • Shannon Lietz, Intuit
    • Milton Smith, Oracle
    • Andi Mann, Splunk
    • Mark Miller, Sonatype
    • Ernest Mueller, AlienVault
    • Karthik Gaekwad, Oracle
  • Why do you need to implement a DevOpsSec team?

    Why do you need to implement a DevOpsSec team?

    Just 20 years ago, organizations relied on a single wall of defense to secure their applications and networks. Fast forward to 2015 and that large fence is no longer adequate. With the proliferation of mobile, cloud and SaaS technology adding to the complexity of ever-advancing systems and networks, it becomes much more important that teams across an organization work together as one, toward a common goal. We’ve already seen enterprises adopting new methods of organizing internal structures to increase collaboration through DevOps, but as security continues to be top of mind for organizations, many are looking to further this approach by including the security team in the DevOps conversation. With a DevOpsSec team, organizations can work toward delivering software that is not just reliable, but also secure.

    Introducing security to DevOps provides the means to this protection by reducing the number of bugs and vulnerabilities during the build process before code hits production systems. Moving security as close as possible to the code and data will bring a large number of high value benefits to an organization.

    The first benefit of introducing security to DevOps is the enablement of team collaboration through tight feedback loops. Development, operations and security teams all have different goals and are motivated by different things, which are often contrary to the other teams. To ensure that these groups don’t work as adversaries within an organization, DevOpsSec encourages them to work together, pulling from all parties’ strengths and building a collaborative and engaging environment. This collaboration offers transparency into the assorted issues that arise within each team, establishing a deeper level of understanding and respect across the board.

    The second benefit is that DevOpsSec provides a wider perspective across previously siloed teams. As a result of greater team collaboration, Dev, Ops and Sec teams are able to gain more insight into how the other teams operate. This widened perspective decreases friction between them, further revealing common goals and generating more natural solutions. Overall, the assortment of perspectives results in more efficient strategies for the organization in keeping its systems secure.

    Lastly, the implementation of DevOpsSec ensures faster response time to issues. As applications and systems become more distributed and complex, it becomes more difficult to identify and fix bugs and vulnerabilities. Developers are writing and pushing code faster than ever before, and what used to be monthly or longer release cycles can now be measured in hours. This is due in part to the fact that code is being used both inside and outside our networks, requiring more thorough network security. The new normal will be found in developing DevOpsSec teams and moving the security as close as possible to the code and data. Through more continuous review processes and more ownership over code in production, the merging of DevOpsSec can mean faster times in closing feedback loops and will ultimately help organizations to operate more efficiently.

    So what will an organization look like after implementing DevOpsSec? As a result of the cross pollination between teams, organizations will have curated an elevated platform for innovative ideas, gained greater insights across teams and developed faster response times to help the business run smoother. With DevOpsSec in affect, organizations will better understand and anticipate security issues and the decisions required to diminish them.

  • Getting Rugged DevOps Right

    Getting Rugged DevOps Right

    Two Perspectives

    Jack, an accomplished application security pro, tells me, “The developers won’t talk to us.  It’s like we speak a different language.  They are releasing new builds so fast, how could they check each one for security vulnerabilities?  We can’t move as fast as they do.”

    Then in the next moment, Diane, a DevOps pro, let’s me know, “Our current security team’s tools and practices can’t keep up with the pace we have now established.  If it doesn’t fit, it doesn’t get done here.”

    I have heard this little ditty ‘bout Jack & Diane so often in the past two years, it could be a hit record. I imagine you have heard it too.

    The Slow Lane Won’t Lead to Rugged DevOps

    Let’s visit Jack’s world, first.

    When visiting a well-known bank last month, they shared insight on their current application security practice.  They have 10 full-time people employed (offshore where personnel costs are lower) to analyze a set of 100 applications.  The bank has over 2000 applications, but the security practice can’t scale to access their entire portfolio.  In 2.5 years, they had only been able to cover 5% of the application portfolio.

    The application security team employs an application security tool originally built for waterfall-centric development timelines.  As much as they want it and need it to move faster, it is not really for “continuous” velocity.

    Each scan of an application can require anywhere from four hours to two days to get an assessment report.  The reports average about 30,000 potential defects which then require further analysis.  That analysis may take up to two weeks in order to sift through thousands of false-positives and false-negatives.  While this security practice is critical to the bank, it cannot keep pace with development practices that are aiming to go much faster in order for the bank to remain competitive in their industry.

    The Continuous Gap

    Sound familiar?  It should.  This scenario is playing out all across the DevOps and Continuous Delivery landscape.  It is reflective of what I call “The Continuous Gap”.

    Leaders in Rugged DevOps practices aim to minimize the “Continuous Gap”.

    In Diane’s world, DevOps teams pursue “shift left” strategies in an effort to build quality in from the beginning.  Shifting left enables them to bake in the right code, components, configurations, and practices from the beginning.  When done right, velocity increases dramatically, while operating costs are minimized, and unplanned/unscheduled work is reduced.  Investments can then shift more in favor of innovation over upkeep and maintenance.

    The Old-School Rub

    Jack’s world of traditional application security practices often wait to check for security vulnerabilities at testing or release stages of the SDLC.  There are two reasons for this: (1) some security tests like static or dynamic analysis can take hours or days to perform and (2) security teams cannot embed themselves earlier in the SDLC (due to political, organizational, or operational obstacles) without dramatically slowing development in a high velocity world.

    If you are using old-school application security tools, you will continue to be blocked from getting more deeply entrenched in development.  New velocity requirements call for new approaches.

    The New-School Shifts Left

    A number of newer application security solutions and practices been introduced recently that are development and developer-centric.  For example, imagine if build managers could analyze every open source component used in every build for known security vulnerabilities.

    What if, developers could access information inside their IDE that would inform them if a component they were planning to use in an application was known to be vulnerable?  What if developers had access to spell-check like alerts of security issues as they were creating their code?

    Furthermore, imagine if information was available that not only told the developer of a known security defect, but directed them to an alternative safer version of that component to use.  Components would be automatically vetted against corporate security policies at the instant they were chosen by a developer.  When 90% of an application is composed of open source and third party components today, automatic analysis early in the lifecycle save millions of dollars.  This how Rugged DevOps rolls.  This is Diane’s world.

    The evolution of Rugged DevOps is forcing application security practices to shift left.

    But Diane’s world (and your’s for that matter) are not just about increasing velocity.  All organizations need to consider operational costs to both detect and remediate security vulnerabilities in their applications.  We all realize that the further along we are in the application development lifecycle the more costly fixes become.  Feel free to apply your own cost figures to the chart below, but you should also note that these calculations do not include breach cost, help desk calls, maintenance, time-to-market, reputation or stock price.

    Rugged DevOps
    Cost considerations for Rugged DevOps practices compared to waterfall approaches.

    Rugged DevOps: Shifting Gears…Quickly

    Shifting from old-school to new school approaches doesn’t take long.  On a recent visit to one of the largest insurance companies in North America, they shared their tale of transition.  Of five major applications that run their business, one in particular had 40,000 different files that needed to be analyzed.  Their old-school approach involved a lot of manual code investigation and required about two-and-a-half weeks to complete the analysis of that large application.  The new approach that used automated analysis of security vulnerabilities took two minutes — and produced identical results.

    A government tax office wanting to shift security analysis of applications from hours (outside of development – Jack’s world) to seconds (inside of development – Diane’s world) was able to complete the first pass analysis of their existing portfolio of 600 applications within two working days.  The security team was not only faster at identifying known security vulnerabilities in applications, but could also quickly identify alternative open source and third-party software components that were safer to use.  The security team was not simply discovering issues, but the new class of Rugged DevOps solutions were aiding in guided remediation.

    Questions to Ask About That Rugged DevOps Solution

    There are several companies and open source projects that now offer application security solutions that work at extremely high velocity.  When exploring solutions to match the velocity of your Rugged DevOps practices, consider asking the following questions:

    1. How long does it take to complete the analysis of a small, medium, and large application?
    2. Do developers use these tools, or are they only meant for security personnel?  Do you have members of development teams that act as positive references for your tool?
    3. Does the analysis require further investigation of the findings, or does it pinpoint the root cause of the issue?
    4. Does the solution only identify vulnerabilities or does it help guide remediation of issues?
    5. What is the balance of false positives to positive alerts generated by the solution?
    6. How many people are employed to support the solution in environments similar to ours?
  • DevOpsSec: Survival is Not Mandatory

    DevOpsSec: Survival is Not Mandatory

    Deming, the patron saint of DevOps once advised, “It is not necessary to change.  Survival is not mandatory.”

    To survive, application development teams are constantly pressured to deliver software even faster.  But fast is not enough.  The best organizations realize that security, quality and integrity at velocity are mandatory for survival. Hence, DevOpsSec

    My aim here is to leave you uncomfortably amazed.  While the pace of development has changed significantly, our processes to secure our applications has not changed enough.  It is as if a wildfire has raged uncontained for years now but we have failed to take notice.

    Maybe that sounds a bit crazy, but once I share a little background on what is happening, you’ll understand why innovation in this arena is critical for survival (when it comes to your applications).  If you are aiming to ramp up your own Rugged DevOps or DevOpsSec practices, this is critical reading material.

    Skyrocketing Usage, Plummeting Visibility

    Open source component use in development is skyrocketing, and for good reason.  Over 17 billion open source and third-party components — across the major development languages — were downloaded last year helping development teams accelerate release timelines and deliver more innovative solutions to market.  To better imagine the impact of this download volume, you need to understand that there are an estimated 11 million developers responsible for the billions of downloads.

    While the magnitude of usage is amazing it has obscured a vast majority of the risks.  Of the billions of downloads recorded last year, 1 in 16 components downloaded had known security vulnerabilities.

    Screen Shot 2015-11-30 at 1.23.55 PM

    While we have seen 30x growth of download requests over the past seven years, we have also witnessed huge growth in the number of organizations improving the speed of consumption and efficiency of their downloads using repository managers.

    In the past 18 months since I joined Sonatype, we have seen active instances of repository managers like Nexus, Artifactory, and Archiva grow from 40,000 to over 70,000 installations, with users in the millions — also for good reason.  Development teams want to ensure faster, more reliable builds.  They also need a private and safe place to house and share their own proprietary components as well as assembled applications, images and other binary outputs.  The repository manager has established itself as a parts warehouse for software development.

    All is Not Moonlight and Roses

    1 in 16 may not sound like a lot until you recognize that many organizations are downloading over 250,000 components every year…some of the largest organizations consume millions of them.  If you have not calculated this in your head yet: 250,000 / 16 = 15,625.

    Screen Shot 2015-11-30 at 1.24.07 PM

    Couple this fact with the remarks in the 2015 Verizon Data Breach and Investigations Report stating that applications were the most often exploited attack vector by hackers.  As a developer community we are electively sourcing known vulnerable components for use in our applications and those applications are now more vulnerable to attack.  

    Your Repository Manager Should Serve and Protect

    If bad components are getting in, why not just stop them at the front door?

    Easier said than done.   Current approaches to preventing such behavior are ineffective.  For some, “golden repositories” are used to house approved components — but components approved once are rarely vetted again for newly discovered vulnerabilities.  For other organizations, OSS Review Boards mandate reviews and approval for all new components — but these organizations are poorly staffed to match the volume and velocity of consumption leading to workarounds by development teams.  And while developers themselves would much prefer to use the best quality, highest integrity components when designing an applications, they are never allocated sufficient time to investigate the vulnerability status of every component required for their latest build.

    Sparking Innovation

    When current approaches fail, inspiration often sparks innovation.  

    Enter, a new invention: a repository firewall.  Think of it as a repository manager with a guard at the front door.  Every component that gets downloaded by a proxy repository is automatically evaluated against the parameters development, governance and security teams establish.  Does it have an AGPL license, include a known security vulnerability, or is it incredibly outdated?  The repository firewall allows organizations to download “good” components while it blocks and quarantines “bad” component downloads.  Using a repository firewall can keep your repository manager and development lifecycle safe and secure – in an instant, automatically.

    The first repository firewall of its kind is called Nexus Firewall.  It couples software supply chain intelligence about component quality, security, and risks with automatic evaluations against personalized policies for approving or rejecting new downloads.  Evaluations can also be applied later in the development lifecycle where staging repositories are in use.

    Screen Shot 2015-11-30 at 1.12.58 PM

    Imagine the result: 16 out of 16 downloads, or 250,000 out of 250,000 downloads are now of the best quality.  Everything flowing into your application development lifecycle contains the highest quality components.  You are instantly compliant with established policies.  Your applications are less vulnerable to attacks.  You are automatically reducing risk.

    Next up in this series, I will share insights about Repository Health Check reports (free to use).  Used by over 15,000 organizations, they can offer organizations the first clue as to whether or not your team could benefit from a repository firewall.  

     

  • DevOpsSec: 1 in 16 Chances

    DevOpsSec: 1 in 16 Chances

    The quantitative research summarized below, covering over 7,000 repositories across nearly 100 countries, highlights some of the challenges with quality at modern development velocities, especially important for DevOpsSec practices. By leveraging automation in your repository manager, you can improve application quality and reduce unplanned work while lowering exposure to risk. While this practice supports DevOpsSec initiatives, at its core, it is simply a focus on “building quality in”.

    (Written as a collaboration between me and Mike Hansen, Head of Products at Sonatype; Mike wrote the better parts.)

    Innovation and Risk

    Repository managers like Nexus, Artifactory and Archiva have been serving software components for development teams and their tooling for years now.  We can measure over 70,000 active repository manager installations across the globe today.  Use of a repository manager improves build performance and reliability while also providing a secure, private location to host open source, third party, and proprietary components needed across continuous delivery and DevOps tool chains.

    Industry averages show software development organizations electively downloading over 240,000 components a year from public internet repositories.  While these components accelerate development and increase innovation, the vast majority of components go through little to no vetting process to determine if known security vulnerabilities, risky license types, or outdated/unsupported are being used.

    DevOpsSec: tracking known vulnerabilities requires better hygiene.

    Earlier this year, researchers found that 1 in 16 downloads includes a known security vulnerability. That accounts for over 15,000 elective downloads of components with known security vulnerabilities per organization, per year.

    Why the Focus on Repository Managers?

    Repository managers like Archiva, Artifactory, and Nexus have become a critical piece of the DevOps toolchains and are commonly used across the entire application lifecycle. It is effectively a binary parts warehouse for your applications. Given how integral this warehouse has become, software supply chain intelligence and automation can be used to significantly reduce unplanned work and eliminate avoidable risk.

    To understand this opportunity, let’s take a quantitative look at the world’s software development ecosystem.

    Global Visibility

    Not long ago Sonatype introduced a free feature in its Nexus Repository Manager that is providing new data on the health of software supply chains.  This features, called Nexus RHC (Repository Health Check) – offers a simple way to get basic visibility into what OSS is flowing into development via your repository manager.  RHC provides a summary of components in the repository that have known security vulnerabilities and risky license types. Usage of this service is now significant, with over 30 million components across over 15,000 Nexus instances being analyzed every day across the globe.DevOpsSec: identifying known vulnerabilities.

    There are also around a million developers using those repositories. With the law of big numbers working for us, we can gain a statistically valid view into the behaviors of the modern software development ecosystem. The findings are quite telling.

    The Data

    We analyzed over 7,000 repositories containing 500 or more software components using the RHC service during the past 90 days. These repositories are representative of those used by development teams in medium to large organizations. The question was straightforward: To what extent are bad things flowing in, causing downstream rework and creating avoidable risk scenarios?

    In three months time, the average number of new vulnerabilities that flowed into the repositories analyzed was 69. That is an average of 23 vulnerabilities per month, which is a little more than one every weekday. If you only include higher risk vulnerabilities – those with a CVSS score of 5 or greater – the average number was 48, or about 16 per month. That is a little less than one every weekday. For a sense of the kind of vulnerabilities in this higher risk category, the Heartbleed bug had a score of 5, the lowest risk in this grouping.

    DevOpsSec: tracking known vulnerabilities.

    These are not isolated instances or outliers. In the set of repositories analyzed, 98.3% consumed at least 1 vulnerable component and 97.7% consumed at least 1 higher risk (CVSS >= 5) component. In a period of just three months, nearly every repository consumed something the organization running it would rather not have, and that is only with respect to known vulnerabilities. There are plenty of other attributes that are worthy of consideration given availability of the corresponding data.

    Whether or not security is of particular concern, the real point is that a lack of visibility and control combined with an abundance of supply has led to inferior quality parts routinely being used by the world’s development organizations, adding avoidable risk and slowing us down.

    Image title

    Going (Way) Beyond Security

     

    The consumption of vulnerable components is a quantifiable problem that we used to illustrate the current challenges that every organization has with open source component selection. However, security vulnerabilities are only one of the many dimensions.

    DevOpsSec: Surveys show the need for improved OSS governance.Others include architectural aspects such as rules covering component age and popularity, intellectual property coverage with rules related to open source licensing and technical debt controls associated with technology stack selection.  Introducing more formalized vetting processes coupled with software supply chain intelligence and automation will yield significant overall quality and efficiency benefits for an organization, allowing them to operate with a lower risk profile.

    Yes, A Firewall for Repository Managers

    In November, Sonatype became the first company to introduce a “firewall” for use with repository managers.  Called Nexus Firewall, the solution offers perimeter quality control for software development. Similar to a network firewall, it leverages rules you define that automatically shield an organization from unacceptable software components entering and another set for stopping them from exiting your application development. The basic concept looks like this:

    Nexus Firewall: shifting DevOpsSec further left than ever before.

    In order to build quality in from the beginning, this solution represents a “shift (far) left” innovation.  The Nexus Firewall improves speed and reduce risk through the quarantine of components with known vulnerabilities. With a repository firewall in place, organizations can shield your application development from waste and risk by automatically blocking unacceptable software components inbound and preventing release of applications containing such components outbound.  1 in 16 downloads with known security vulnerabilities could be reduced to zero in 16.

    The firewall also goes beyond blocking, providing organizations with the visibility and data needed to make ideal decisions for open source component selection early, significantly reducing waste related to rework and eliminating avoidable risk.

    For DevOpsSec, Shift (Far) Left to Build Quality In

    The consumption of these unacceptable or, at a minimum, inferior components is unnecessary.  For the vast majority of these vulnerable components, there are non-vulnerable alternatives ready to be used in their place. The challenge is that it has been historically difficult for developers to understand these risks and even harder to avoid them.  Few developers have countless hours to commit to researching vulnerabilities in the components they use and fewer more want to rely on colleagues in security, legal, or audit teams to spend hours or weeks to return with “go” or “no go” vetting decisions.

    The volumes and velocity of component consumption we see today validates that any form of manual review process or automated workflows outside of the development teams will be quickly outpaced.  DevOps and Continuous Delivery processes need to rely on automatic intelligence to help developers select the highest quality components and avoid those with known risks.  When known security vulnerabilities and other risks are identified, software supply chain intelligence will be required to guide developers through the identification and selection of safer, higher quality components.

    An example of the kind of information made available is shown below.

    DevOpsSec: Identify the best components that meet policy guidelines from the beginning.

    The information is divided into two areas. On the left side is component data, which includes details related to the component itself. To the right, there’s a graphical display of any security or license issues, as well as popularity data for each version of the component displayed. Selecting different versions updates this information accordingly, including whether or not a particular version passes the established criteria.

    A Must for DevOpsSec: Quality at Velocity

    Simply by enabling a repository firewall, organizations can immediately improve quality and reduce waste and exposure to risk. None of this comes at the expense of development speed.

    The repository firewall automatically quarantines components that do not pass your rules preventing quality issues from entering the software being developed, immediately reducing risk and avoiding wasteful rework at some later point. Quality is improved, efficiencies are gained and risk is reduced, all through automation and all at the speed of modern development.

    One of my favorite reference books is Continuous Delivery by Jez Humble and Dave Farley.  Let me share a few of their words to help remind us of the importance of innovations and practices that allow us to bring pain forward.  Jez and Dave remark:

    “The techniques that we describe in this book, such as continuous integration, comprehensive automated testing, and automated deployment, are designed to catch defects as early in the delivery process as possible (an application of the principle “Bring Pain Forward”).  The next step is to fix them  A fire alarm is useless if everyone ignores it.  Delivery teams must be disciplined about fixing defects are soon as they are found.”

    Well said Dave and Jez.  Well said.

     

  • Rework is Choking Software

    Rework is Choking Software

     

    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.

    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.

  • 2015 State of the Software Supply Chain Report

    2015 State of the Software Supply Chain Report

    In April of this year, I embarked on a six-week journey diving deep into an analysis of the world’s software supply chains.  I evaluated the practices of 106,000 organizations, the 100,000+ suppliers they relied on, and the billions of software components that fueled their agile, continuous delivery and DevOps practices.

    The facts I discovered and share in the 2015 State of the Software Supply Chain Report: Hidden Speed Bumps on the Road to Continuous, (pre-register for the full release: Tuesday, June 16th) fundamentally changed the way I thought about software (and about DevOps).

    The volume and velocity of consumption, the variety of parts and suppliers, and the impact on innovation and quality astounded me.  Early reviewers of the report including Gene Kim (co-author of the Phoenix project), Gareth Rushgrove (Puppet Labs and DevOps Weekly newsletter), Nick Galbreath (Signal Sciences), and Nigel Simpson (Fortune 100 Entertainment and Media company) agreed.

     

    Screen Shot 2015-06-03 at 10.28.51 AM

     

    My aim for this research is not simply to present facts about the global software ecosystem.  I’m aiming to point a spotlight on software supply chain best practices within across a variety of industries that could be used as new benchmarks for software supply chain automation.  Similar to manufacturing of auto, pharmaceutical, healthcare, or defense systems, the effective management of supply chains will create winners and losers.  I’ll share evidence that the best, high-performance software development organizations are benefiting from:

    • Working with fewer and better suppliers
    • Relying on the highest quality supplies from those suppliers
    • Maintaining  traceability and visibility throughout the software supply chain for prompt and agile recall

    Key Points from the Study

    In the best organizations, the research revealed developer net productivity increasing by up to 40%. Just imagine applying that time to more innovation, rather than to rework and maintenance efforts.

    At the same time, the report touches on inefficiencies and complexities that are creating a huge drag on the velocity software development teams are aiming to achieve.  A lack of discipline, focus, and visibility around the software supply chain has resulted in mountains of technical debt, unnecessarily context switching, and outdated sourcing methods that wasted over 3.3 million build days last year alone.

    Hightlight: Automation Across the Software Supply Chain

    The other key insight from this research is the clear need for further automation across software supply chains.  With individual organizations consuming hundreds of thousands and sometimes millions of software components annually, it became obvious that waterfall-centric approaches to identifying the most functional parts, checking quality, validating appropriate licenses, or evaluating security vulnerabilities could not keep pace.  Sourcing practices that regularly go unchecked have also resulted in the use of severely outdated software components, even numerous versions of the same component part.

    Download the Full Report

    Over the next few weeks, I will publish excerpts of findings and best practices identified in the 2015 State of the Software Supply Chain Report and invite you to read along.  Or you can access the full report now through this link.

  • A True Story: DevOps(Sec) Manages Out Elective Risks

    A True Story: DevOps(Sec) Manages Out Elective Risks

    A True Story

    There are over 2000 developers in Bill’s organization.  He is a C-level executive for one of the largest insurance companies in North America. Bill boosted developer productivity by 15% last year after taking a closer look at the company’s software supply chain. And this approach isn’t unique to Bill’s organization.  Many high performance IT and DevOps teams are adopting proven supply chain principles to accelerate software delivery.

    Origins, Quality and Integrity

    The concept was rather simple and straightforward.  Bill’s team recognized that they were consuming hundreds of thousands of open source and third-party software components to build their applications.  But at the same time, they did not apply much scrutiny to the origin, quality, age, or integrity of those components.  Developers simply selected components at-will that met their functional requirements and helped them meet the next delivery deadline.

    Secrets of the Free-For-All

    Deeper analysis of their practice revealed that the free-for-all component sourcing methods were leading to quality, efficiency, and productivity issues.  Here is what Bill found:

    • The company had downloaded an average of 27 versions of over 100 different binary artifacts over a one year period.  Bill knew this meant the quality of their applications was being impacted through the use of outdated software components.
    • The company had also downloaded 13,203 software components with known security vulnerabilities — and 65% of those included alerts earlier than 2014.  Without quality controls in place, Bill recognized they were sourcing in elective and avoidable risks that would impact the integrity of their application, grow their technical debt, and lead to more rework down the road to replace the flawed components.

    Removing Complexity

    Bill decided to take action.  He knew that to accelerate innovation, he needed to remove complexity from the company’s software supply chain.  He enacted three moves to eliminate waste and complexity within the open source and third-party components being used:

    1. Automate the scrutiny of software suppliers to minimize risk and bloat.
    2. Enable real-time traceability and visibility to components used across the development lifecycle, in order to improve response times when defects were discovered – cutting back from days/weeks to minutes!
    3. Reducing complexity, rework and risk by standardizing on specific components types (e.g., web frameworks, logging frameworks, encryption modules), using fewer and more current artifact versions, and managing out elective security risks.

    Want to hear the rest of the story?

    The same principles that Bill applied to his business that boosted developer productivity by 15% are being discussed by Gene Kim (@RealGeneKim), author of The Phoenix Project, and Joshua Corman (@JoshCorman), CTO of Sonatype, on April 30th.  Both Gene and Josh are huge fans of marrying DevOps practices with leading supply chain management principles that enable developers to maximize throughput of features from “code complete” to ‘in production,” without causing chaos.

    If you’re looking to achieve similar goals, be sure to join Josh and Gene for this April 30th, 1pm ET, discussion.

     

    josh corman, gene kim