staging-devopsy.kinsta.cloud

Tag: devsecops

  • DevDredOps

    DevDredOps

  • 7 Things to Make DevSecOps a Reality

    7 Things to Make DevSecOps a Reality

    While talking about DevSecOps has become a hot trend, it is clear that many organizations claiming to follow such methodologies are actually mired in traditional waterfall development. Let’s figure out if you’re really ready to implement DevSecOps.

    In a world that relies heavily on distributed computing and third-party services, security is paramount for those who want to remain competitive. From open source applications to operating systems developed, deploying, delivering and correcting application vulnerabilities must occur rapidly before breaches or compromises occur.

    Here’s the good news: If your company practices authentic agile development and uses highly modular design patterns such as service-oriented architecture, you are well-positioned to achieve DevSecOps success. Why? Because you are already using key strategies that provide solid foundations for secure computing solutions, so you can immediately start experiencing the benefits that come from doing DevSecOps right.

    Follow the Exact Recipe: Don’t Cherry-Pick Ingredients

    DevSecOps emerged from people realizing that DevOps did not adequately highlight security concerns and security should be shifted farther left in the software development life cycle. You should think of DevSecOps as sweetening the existing “recipe” of DevOps by baking security in from the beginning without slowing down the development and release cycles. It may sound obvious, but increasing velocity while reducing risks will guarantee the release of better products because they are built with potential risks in mind (for instance, more and better error handling). This approach results in happier customers and repeat business, which will positively impact your bottom line.

    DevSecOps Requires a Shift in Culture and Mindset

    Let’s face it, the days of successfully deploying applications designed to meet business demands without embedding security controls early in the development life cycle are gone. Effective DevSecOps spans culture, practices and tools that break down silos, orchestrate integrated processes with automated tasks and simplifies security by bringing it out into the open. Instead of “security through obscurity,” boundaries and channels are clearly defined and narrowly focused.

    The benefits of DevSecOps are many and include:

    • Automating security review and application testing.
    • Increasing the speed of delivery enhances product quality.
    • Enhancing compliance with continuous monitoring and auditing.
    • Fostering transparent and open cultures.
    • Reducing costs, development church and application attacks.
    • Delivering increased security and confidence.

    A methodology that uses communication and collaboration to allow for dynamic development and deployment is crucial for responding to change and needs rapidly. When done right, this new mindset will make everyone in your organization accountable for security with a simultaneous mind and talent shift.

    Putting DevSecOps Into Practice: A Checklist

    An efficient DevSecOps program will require continuous management and developer education and process improvement through open collaboration, proactive monitoring and informed feedback. Here’s a short checklist to ensure you’re on the right path.

    1. Build an Environment Conducive to DevSecOps: Engage leaders with a new mentality that makes it incumbent on leadership to understand engineering practices, so they know when things need shorting up. Deeply integrate management, so they support the necessary investments in tools and training while encouraging teams throughout the entire development life cycle.
    2. Ensure Open Communication and Active Training: Promote collaboration and ongoing learning that leads to continuous improvement across the organization. Do this well by providing developers with the training and tools they need. Enable failing fast, early and often so you learn from it and create something useful.
    3. Adopt a Security-Conscious Culture: The driving force behind DevSecOps requires security to be defined at the beginning of a project for repeatable, consistent use. This practice will help you respond to security needs and changes quickly while increasing team collaboration.
    4. Implement Infrastructure as Code (IaC): Without relying on manual processes, IaC helps manage and provision infrastructure automatically. This approach allows code to automatically be rolled out in a repeatable and consistent manner through a version-control system instead of relying on installation gurus and “component owners.”
    5. Use Genuine Agile: Instead of cherry-picking from the agile approach and using your own form of agile-flavored waterfall—focus on practicing “Pure Agile.” This method includes detailed and frequent stakeholder involvement, “fail fast” practices and processes, a “meet the requirements” values and principles mindset and technical excellence.
    6. Adhere to Modular Design Patterns Closely: While object-oriented design (OOD) and service-oriented architecture (SOA) mean different things to different people, the commonly understood key is decomposing large business problems into small business problems that can be addressed by discrete services through boundaryless information-flow sharing.  When done correctly, OOD and SOA will help your applications scale quickly while decreasing costs.
    7. Favor Resource Management over Pride of Ownership:  There is a now-famous analogy about thinking of software components more like cattle than like pets.  While grim, the point is a salient one: When something fails, you should be able to quickly replace it with a new or improved component instead of trying to nurse the ailing component back to health. This mindset better promotes modularity and discreteness of purpose, which, in turn, leads to faster fix and restoration times.

    As virtual environments and cloud usage grow, the need for DevSecOps to be done “the right way” is growing right along with it. But the sense of urgency to implement DevSecOps practices “the right way” hasn’t quite caught up yet. The challenge is to embrace all aspects of DevSecOps day in and day out, instead of just going through the motions of the select practices you adopted.

    The call to action is clear: Now is the time for organizations to move the speed of delivery and secure code out of the textbooks and manifestos into the mainstream.

  • DevSecOps and Passwords: Lessening the Burden

    DevSecOps and Passwords: Lessening the Burden

    The point of DevOps is to make IT more responsive (and hopefully more stable, but we have evidence that is not always the case). The point of DevSecOps (so far) is to make security more responsive and to build security right into the stack. These are both worthy goals. As we all have pointed out repeatedly, an already overworked security team needs DevSecOps to keep up with the increased rate of change that a more responsive IT department represents.

    And yet, while we’re automating and simplifying things, the security end of DevOps is doing little for end users. Automating protection of App X is good for the App X team and good for the company, but it means little to the ultimate users of security. We all know security is a burden that users bear in the hopes of protecting the company, but no one is a fan. So maybe you didn’t have self-service password management, and now you do. Great! That helps end users. But most of us were already implementing self-service in an attempt to lift some of the load off of the security and help desk teams by the time DevOps took hold.

    Maybe you’ve implemented SSO as a result of DevOps. Again, good move! Employees spend less time remembering passwords and more time being productive. There’s less stress, too. But again, that was already well along, DevOps or not. And you know what? Employees are still making passwords they can remember, writing down passwords, re-using the same complex password, etc. To make it more difficult to hack, IT has come up with all sorts of strange rules such as, “Password digits, when summed, must be divisible by the square root of pi …” but that does little if the same password is used for LinkedIn (because it is “work-related”) and LinkedIn gets hacked again. And don’t fool yourselves, I know tech-savvy people who do this. Non-technical people are doing it a lot if techies are doing it.

    Which brings us to my suggestion: Your DevSecOps plan should include a password manager budget. There are a ton of them available, they’re cheap enough no matter which one you choose and they will generate complex passwords and then remember them for the user. Give employees password managers, train them a bit on their use, and reduce the chances that their password is the same as the one they used at pleasehackme.com. The investment is small—a few dollars per user for most managers—and choices include vaults that are local or hosted and the ability to set password-generation parameters.

    The only problem with a service-based password manager is ownership of the account after the employee leaves the company, but a policy can clearly delineate when responsibility transfers to the user and arrange for removing them from systems at the same time.

    More secure, less user hassle (true single sign-on, since they only need to know the password to the password management tool) and low cost—this is the heart of DevSecOps. And the investment is small. A bit of cash, a bit of training. What’s not to love?

  • DevOps and Security in a Cloud-Native World

    DevOps and Security in a Cloud-Native World

    DevOps teams have naturally embraced microservices and modern application delivery workflows. But, they may get pushback from risk-averse leadership or feel slowed by security teams who struggle to keep pace. Development teams that play a greater role in guiding their organization’s cloud transformations will ultimately come out ahead.

    These are some of the takeaways from the largest and most globally expansive market research dataset on cloud-native security to date, the “State of Cloud Native Security Report 2020,” from Palo Alto Networks.

    Analyzing the data with a DevOps point of view may help your organization navigate its own transitions.

    Cloud Native Architectures and Security: What it Means for DevOps

    Organizations estimated that, on average, 46% of all workloads are already in the cloud and 95% of respondents expect that number to increase over the next 24 months. This likely means more resources and deployments for DevOps teams, but also means that security needs to meet the needs of these cloud workloads.

    Change is constant in cloud infrastructure

    Most survey respondents (80%) said their company’s cloud infrastructure is constantly evolving. This consistent change stems from companies experimenting and evaluating new cloud offerings, finding best practices and exploring new services.

    But this constant change impacts security teams and their tooling. Both in how they can continuously audit and protect cloud native applications today, as well as how they need to strategize on any anticipated change in the future—75% of respondents worried that cloud threats already outpace security.

    Multi-cloud is the industry standard

    DevOps teams have more options than ever before for running cloud-native apps. Nearly every organization surveyed—90%—confirmed they use more than one cloud platform. And respondents are using a combination of compute architectures: VMs account for 30% of workloads on average, with containers at 24%, CaaS at 21% and PaaS at 22%.

    As DevOps teams take advantage of increasing platform/compute permutations, security teams need both wider and deeper visibility across cloud infrastructure. For some security teams, this has meant more tooling—57% of teams reported using more than five security tools and some up to 11 or more—which may mean a proliferation of workflows, policy engines and dashboards.

    DevOps and security aren’t concerned with any single threat

    They have many that they prioritize differently. When asked for the No. 1 threat, no single answer stood out. Instead, 10 ranked about equally in frequency:

    • Data exposure (13.2%)
    • Malware (12.8%)
    • Application vulnerabilities (10.9%)
    • Weak and broken authentication (10%)
    • Insider threats (9.7%)
    • Credential leakage (9.1%)
    • Insecure APIs (9%)
    • Infrastructure misconfigurations (9%)
    • Application misconfigurations (8.7%)
    • Over-permissioned access and misconfigurations (7.7%)

    This means that DevOps and security teams may sometimes clash about what needs to be the highest priority and how to ensure they are meeting a high level of security.

    While many organizations feel that the diversity of cloud and the speed at which it changes can cause gaps in security, it also suggests there are ways to successfully minimize risks.

    Embedding Security Across the Application Life Cycle

    The survey analyzed the types of actions companies take in their cloud security, then created a ranking based on responses. (Details are available in the report.) Companies with the highest-level preparedness ranking were found to have many of the same habits.

    Many highly prepared organizations (45%) embed security into their DevOps processes and almost as many (41%) integrate security in at least four stages of the development life cycle.

    In addition to shifting security left, these organizations automate many security practices such as configuration monitoring and vulnerability scanning/management, eventually implementing guardrails or quality gates into their regular workflows.

    DevOps teams should work with leadership and security to identify consolidated platforms that can scale to continuously monitor configurations and protect the continuum of compute options discussed above. These types of platforms that can integrate security across the development life cycle are beginning to gain more attention and are becoming increasingly practical solutions.

    Next Steps

    The survey data makes clear that the cloud will continue to evolve as it matures, and it will remain multi-everything. It also suggests there are things DevOps teams can do to help set the model for how cloud is adopted in their organization.

    Security and development teams will need to increase collaboration to identify threats and controls. By shifting left and inserting security to the earliest possible point in the development process, using platforms that integrate across the life cycle, threats or vulnerabilities can be anticipated and their impact reduced.

  • Automation: The Human-Free Zone Approach to Software

    Automation: The Human-Free Zone Approach to Software

    Humans hate repetitive manual tasks. We suck at them—we make mistakes, lose concentration, get bored. Throughout history, humans have instinctually developed automation to keep us away from the hazard-prone, tedious work of these tasks.

    In software, we use configuration management, deployment tools and lean/agile processes born out of factories and the automation principles established there to automate the software factory. Utilizing automation reduces software errors and increases reliability and productivity by allowing the work performed to scale to hundreds and even thousands of systems.

    As we’ve written scripts and functions to help ourselves, we’ve had to implement access control, least privilege, two-person rule and other security principles to secure against the human threat and to prevent catastrophic loss through either a malicious actor, leaked credentials or other type of compromise. And this problem gets more complex and difficult the more automation is involved. However, what if we harness the power of automation to solve our security risks—to remove the human threat mostly or entirely from production by enforcing a single path to production via CI/CD pipelines, building and deploying signed artifacts and system hardening including explicit removal of human/remote access?

    With this, we can validate the chain of custody on all changes to the system while also proving that outside actors cannot make unauthorized changes. This is what we’re looking for when we talk about DevSecOps.

    Automation to the Rescue

    Here are the processes humans should be fully or at least partially removed from to optimize software effectiveness, security and efficiency:

    • Code and pipeline.
    • Artifact deployment.
    • Automated access.

    Code and Pipeline (partial human interaction)

    Let’s start on the left, with our code and pipeline. The rules here are simple and familiar. We start with source code management and the two-person rule. No one individual can write and commit code without approval from someone else. Implementing the two-person rule as well as securing production access ensures that access control happens solely within the pipeline and we have full enforcement of the two-person rule. We can have a full team review along with static code analysis, but the core rule is that no one person has the power to write and commit code, ensuring that a single human cannot be responsible for making a change.

    The code repository is watched by our pipeline with the task of testing, building and verifying a versioned artifact. This artifact is everything in our code at a moment in time. When we think about rollback scenarios, we’re thinking about deploying the previous artifact. This artifact is checksummed so we can attest to its integrity at any point, and we can validate the checksum by pulling the code and building it ourselves.

    Artifact Deployment

    And we need an artifact for not just our application code from development, but also based on what the infrastructure looks like from Operations. This is part of the promise of DevSecOps: Ops writes code that gets checked into repositories just like Development. This allows us to pair our application artifact with our operations artifact. These artifacts together are what we deploy—the system at a moment in time and the application at a moment in time. So, at this point, we’ve established that two humans (at least) have looked at the source code and, once committed, that our pipeline has picked up those changes, performed static code analysis on it and created signed artifacts, ready to be deployed to a test environment. Now that we have our artifacts, we need to deploy them.

    Again, the goal is to not use humans, so after our artifacts are built we must test deployment. The way we ensure security is having the pipeline push the artifacts to a secured artifact store and our systems pull from there as we approve environments to receive the update. This accomplishes two important things: First, by having a push from our pipeline, we again maintain that chain of custody tracing back to source control. Second, we limit which environments are updated by having those systems subscribe to the appropriate artifact stores. The only work humans do here is performing testing and deciding when to promote. The automation actually takes care of the actual promotion work. Now finally, we have the ability to run our artifacts in production.

    Automated Access

    The idea of a continuous delivery pipeline isn’t new and is practiced by many teams today. What we’re going to add to this is a production system that does not have inbound access.

    Because in this design systems pull from the artifact store, the only rule needed is outbound from production to the artifact store. This means you can disable remote management entirely, trusting fully in the chain of custody established in the pipeline. This trust, along with ensuring remote management is disabled, establishes the human-free pipeline. We have shifted user access focus into source code repositories and into the management of the CI/CD pipeline. We have visibility into every stage of the process and eliminated the need for users to have login credentials to production systems. The credential management is also a function of pipeline management, drastically reducing its complexity.

    This is what it means to practice DevSecOps—understanding how automation actually enables the security team to reduce the complexity of our security model and gets security out of the role of blocker and into enabling the business.

  • Upcoming Event: GitLab Commit Virtual 2020

    Upcoming Event: GitLab Commit Virtual 2020

    For the first time ever, GitLab’s annual user conference will take place in a virtual environment on Aug. 26, bringing together DevOps luminaries from around the globe for a free, interactive learning experience.

    GitLab Commit Virtual is a 24-hour virtual event that provides attendees with the opportunity to join DevOps discussions, demos and presentations, and network with thought leaders from the industry’s top companies, such as Microsoft, Google, Hubspot, Forrester and many more.

    Speakers will showcase the power of community and share DevOps best practices through strategy and technology discussions, lessons learned, behind-the-scenes looks at the development life cycle and more.

    The agenda for GitLab Commit Virtual features a mix of topics, including technical sessions, live coding, deep-dives and case studies covering DevSecOps, containers, Kubernetes, CI/CD, open source, all-remote and more.

    The virtual environment features a lobby, an expo hall lined with booths full of downloadable resources and an auditorium where attendees can watch sessions by industry leaders.

    This year’s GitLab Commit features more than 40 sessions from some of the most brilliant DevOps experts, including:

    • “DevOps Works! Why Hasn’t Security Kept Up?,” a keynote session by Joni Klippert, StackHawk.
    • “DevSecOps in Government and Highly-Regulated Industries,” a keynote session by Nicolas Chaillan, U.S. Air Force.
    • “Real World DevOps,” by Abel Wang, Microsoft.
    • “Why Your Organization Should Embrace the Community Model,” by Karl Cardenas, State Farm.
    • “Getting Fuzzy: Blurring the Lines of Traditional QA and Security Testing,” by David DeSantos and Sam Kerr, GitLab.
    • “How the U.S. Army Cyber School Created ‘Courseware as Code’ with GitLab,” by Ben Allison, U.S. Army Cyber School.
    • “Measuring DevOps,” by Nathen Harvey and Dina Graves Portman, Google.
    • “How To Create an Equitable and Inclusive Culture That Transcends Physical Walls,” by Eimear Marrinan and Meaghan Williams, HubSpot.

    By visiting the expo hall, attendees will also be able to interact with sponsors, including AWS, Google Cloud, Lightstep, HashiCorp, Red Hat, VMWare Tanzu and WhiteSource.

    Attendees will get a deep dive into how enterprises are transforming DevOps at an organizational level and how they can implement similar practices in their own organization.

    To see the full agenda and to register, please visit the GitLab Commit Virtual website.

  • MuseDev Offers DevOps-Optimized Security Code Analyzer

    MuseDev Offers DevOps-Optimized Security Code Analyzer

    MuseDev today announced it has made available on GitHub under an early access program a code analysis tool dubbed Muse that is designed to surface cybersecurity issues as pull requests are made from the repository.

    Company CEO Stephen Magill said rather than waiting to discover cybersecurity issues after an application is deployed, Muse makes it easier for IT teams to consistently employ best DevSecOps practices.

    There’s general agreement DevOps teams should assume more responsibility for application security as part of any quality assurance process. However, DevOps teams have lacked access to tools that would make it easier to incorporate security analytics within the context of existing application development and deployment workflows, said Magill.

    Muse is also designed to surface cybersecurity issues in a way that makes it easier for developers to comprehend, said Magill. MuseBot automatically analyzes each pull request and delivers bug reports in GitHub as code review comments. In contrast, he noted, code analysis tools employed by cybersecurity teams tend to surface lists of vulnerabilities without providing developers with enough context to remediate or even prioritize.

    Muse is also designed to provide a faster alternative that generates results in about 20 minutes, which means DevOps teams can address issues within a workflow versus waiting for a report from a cybersecurity team, noted Magill.

    Too often code analysis tools will also generate too many false positives, he said. Muse includes a broad set of tools such as ErrorProne, Infer and Pyre for various cloud platforms that are customized and configured to reduce alert noise. Muse also provides access to an open application programming interface (API) that makes the platform fully customizable, Magill added.

    Muse is available as a GitHub app that the company is promising will be free always for open source projects and other public GitHub repositories. Analysis of private repositories is also available at no cost. A self-hosted Enterprise version available for GitHub, Bitbucket and GitLab, scheduled to be generally available by the end of the year, is also available as a private beta. MuseDev is also making available a professional services team to help organizations implement the platform.

    The company itself was spun out of Galois, a research and development firm that specializes in cybersecurity.

    In general, it can cost organizations as much as 10 times more after an application is deployed in a production environment to address cybersecurity issues. Despite widespread awareness of that issue, adoption of best DevSecOps practices within many organizations remains relatively nascent. There’s a lot of interest in DevSecOps as a goal, but few organizations have been able to put the tools that are needed to construct security workflows into the hands of DevOps teams.

    However, as more DevSecOps tools become available, chances are a lot of progress soon will be driven from the bottom up in most organizations rather than from the top down.

  • Veritas Looks to Reduce Data Protection Costs

    Veritas Looks to Reduce Data Protection Costs

    Veritas has extended the capabilities of the company’s NetBackup software as part of an effort to reduce the total cost of data protection.

    Version 8.3 of NetBackup now includes Veritas Resiliency Platform (VRP), a disaster recovery tool, and CloudPoint, a tool for backing data up on a public cloud. All of these tools are part of what Veritas calls its Enterprise Data Services Platform (EDSP).

    In addition, Veritas has integrated hardened NetBackup appliances and vendor-agnostic immutability for storage via its NetBackup OpenStorage Technology (OST) to help organizations recover from a ransomware attack more easily.

    Veritas is also adding support for 2048-bit encryption and integration with third-party key management systems (EKMS) along with more flexible enhancements to the role-based access control (RBAC) it provides.

    Other capabilities in this release of NetBackup include more granular recovery of virtual machines, the ability to orchestrated rehearsals to verify effectiveness of recovery procedures, and the ability to move data between cloud platforms.

    Veritas has also extended discovery, backup, restore and automation at scale for Microsoft SQL, Oracle and Oracle Real Application Clusters (RAC) to simplify data protection processes spanning multiple classes of databases.

    Finally, Veritas claims with this release, data protection via auto-discovery of resources and load balancing is now 25% faster and the discovery of VMware vCenter and vCloud platforms is 50% faster.

    Doug Matthews, vice president of data protection and compliance for Veritas, said with the expansion of EDSP it’s now much more cost-effective to protect data residing on multiple platforms. In the wake of the economic downturn brought on by the COVID-19 pandemic, there’s much greater sensitivity to IT costs, he said.

    At the same time, Matthews said Veritas is seeing DevOps teams become much more involved in automating data protection processes. Veritas has defined more than 600 application programming interfaces to enable DevOps teams to programmatically invoke its data protection software, he said.

    Cybersecurity teams are also becoming more involved as backup and recovery becomes a core element of ransomware defense strategies, Matthews added. In an ideal world, anytime a ransomware attack occurs, a pristine copy of any impacted data would be readily available on another unaffected platform.

    The convergence of data protection and cybersecurity has been a long time coming. Symantec once owned Veritas in the hopes of achieving that goal. Now Veritas is working with a much broader array of third-party partners to achieve that same goal, Matthews said. It may wind up being the rise of DevOps that finally forces that issue as data protection becomes one more IT task to be automated.

    In the meantime, IT organizations may want to revisit their entire approach to data protection. Chances are good that most of them have multiple redundant data protection tools and services in place that have been acquired over time. Consolidating those functions ultimately not only reduces licensing costs, but it also creates an opportunity to automate a set of mundane tasks that all too often IT staff forget to perform consistently at a time that will prove crucial.

  • Upcoming Event: DevOps India Summit 2020

    Upcoming Event: DevOps India Summit 2020

    DevOps experts and business leaders from across the globe will come together to share their thoughts on DevSecOps, security and governance in DevOps during the third edition of DevOps India Summit (DOIS). Presented in a virtual environment, DOIS20 will take place on Sept. 9, at 9 a.m. IST.

    At DOIS20, attendees will have the opportunity to interact with industry experts and learn how they have successfully implemented DevSecOps practices. The DevOps practitioners will share their experience and expertise, focusing on their company’s transformation to DevSecOps.

    DOIS20 features an exceptional lineup of more than 35 DevOps thought leaders, including:

    • Mark Miller, senior storyteller and DevOps advocate at Sonatype (keynote speaker)
    • Piotr Lewandowski, senior staff site reliability engineer at Google Cloud (keynote speaker)
    • Alan Shimel, founder and CEO at MediaOps (keynote speaker)
    • Mirco Hering, global DevOps practice lead at Accenture (keynote speaker)
    • Rosalind Radcliff, distinguished engineer and chief architect for DevOps at IBM
    • Dr. Niladri Choudhuri, founder and CEO at Xellentro
    • Hasan Yasar, technical director at Software Engineering Institute
    • Sanjeev Sharma, co-founder and principal analyst at Accelerated Strategies Group and author of “The DevOps Adoption Playbook” and “DevOps For Dummies”
    • Vandana Verma, Global Board of Directors at OWASP Foundation
    • Ramesh Pasapula, assistant vice president at Wells Fargo
    • Sailaja Vadlamudi, director of security and data privacy at SAP Labs and WiCSP founder

    The online environment at DOIS20 features a lobby, an expo hall lined with booths full of downloadable resources and an auditorium where attendees can watch sessions from 8 a.m. to 6 p.m. IST. The expo hall will be open throughout the event, giving attendees the opportunity to chat with vendor sponsors and download information.

    All registered attendees will have the chance to participate in contests and win incredible prizes, attend Q&A sessions with the speakers and will also receive a link to access the virtual summit on-demand.

    For more information and to register, visit the DevOps India Summit 2020 website.

  • Snyk Tool Prioritizes Open Source Vulnerabilities

    Snyk Tool Prioritizes Open Source Vulnerabilities

    Snyk today announced it has enhanced the ability of its namesake vulnerability scanning tool by adding the ability to identify which open source vulnerabilities should be fixed first using a scoring tool that leverages data science and machine learning algorithms to analyze code.

    In addition, DevOps teams can now take advantage of automated pull requests to fix those vulnerabilities.

    Finally, DevOps teams also can define policies that require certain classes of vulnerabilities to be fixed whenever they are identified.

    Aner Mazur, chief product officer for Snyk, said given the number of open source modules employed and the dependencies that exist between them, staying current on patches and updates has become a major challenge. The only way to achieve that goal is to rely more on tools that help automate that process, he said.

    These days it’s easy for development teams to feel overwhelmed by patch requests to fix open source security vulnerabilities. The trouble is, not all those requests are of equal weight. Snyk provides tools that enable developers to understand which vulnerabilities are of the highest severity and how they might impact their code.

    Armed with that insight, Mazur said, it then becomes possible to prioritize remediation tasks within the context of a DevSecOps process. Otherwise, developers will simply fix vulnerabilities regardless of relevance as time allows. Developers may remediate dozens of bugs only to discover that a critical flaw that had been left unaddressed led to a major compromise.

    It’s also not uncommon for DevOps teams to fail to appreciate dependencies between open source code modules. When patches to code are applied in the wrong order, an application can break, resulting in DevOps teams having to start the whole process over. The prioritization tools provided by Snyk prevent that from occurring, Mazur said.

    In the absence of any ability to prioritize vulnerabilities, developers eventually become inured to patch requests because they don’t know whether their patching efforts are making any real difference, he added.

    Worse yet, all the time spent on patching low-level vulnerabilities reduces the amount of time developers have available to write new application code. In fact, one of the paradoxes of DevOps is as the number of applications deployed increases so too does the amount of time spent debugging them. Before too long, a DevOps team can find itself spending more time fixing existing code than developing new applications.

    As DevOps teams become more dependent on open source code, they benefit from the collective security efforts of all the contributors to that project. The result is more secure code, as patches to remediate specific issues are made available. The challenge now is finding a way to automatically apply those updates in a way that doesn’t conspire to slow down the overall application development process. Achieving that goal requires visibility into what is now a multitude of open source projects that no DevOps team is ever going to be able to consistently achieve on its own.