devopsy.kinsta.cloud

Tag: vulnerabilities

  • 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.

  • Puppet Aims to Automate Vulnerability Remediation

    Puppet Aims to Automate Vulnerability Remediation

    Puppet today unveiled Puppet Remediate software, which makes it easier to prioritize and remediate software vulnerabilities automatically.

    Matt Waxman, vice president of products for Puppet, said Puppet Remediate builds on existing automation capabilities in the Puppet platform to make it easier for DevOps teams to focus on addressing vulnerabilities. Most existing approaches to addressing vulnerabilities rely on manual processes that often result in vulnerabilities not being addressed in an especially timely manner, he said.

    To accelerate that process, Puppet Remediate identifies vulnerabilities based on their potential severity and then gives DevOps teams the option to automatically remediate all known instances of that vulnerability, said Waxman. Puppet Remediate combines infrastructure data with vulnerability data gathered in real-time from Tenable, Qualys and Rapid7 to prioritize vulnerabilities.

    Puppet Remediate will not automatically remediate a vulnerability without the express approval of the DevOps team. That’s critical because in many instances the patch being applied still needs to be tested and vetted by the DevOps team, noted Waxman. Once approved, Puppet Remediate includes four pre-built tasks that allow DevOps teams to address more than 80% of the typical remediation workloads—importance because once a vulnerability is discovered, it’s not uncommon to find that same mistake has been made across many other software modules that have already been built and deployed.

    Deployed using Docker containers, Puppet Remediate relies on an agentless approach to vulnerability remediation that adds minimal overhead to either a Linux or Windows application environment, Waxman said. He added the goal is to make it easier for developers or cybersecurity teams to deploy Puppet Remediate on any platform.

    Waxman said the primary goal is to help organizations embrace best DevSecOps processes. In the absence of automation, the amount of time allocated to addressing vulnerabilities manually within existing applications often gets short shrift as developers race to meet deadlines for new applications. The irony, of course, is that each new application only serves to increase the number of potential vulnerabilities that need to be addressed. To restore order to vulnerability remediation process, Puppet is making the case for applying a proven IT automation framework to application security management.

    It may take a while for organizations to fully embrace automated application vulnerability remediation, but it would seem that, given the chronic shortage of cybersecurity professionals, adoption of these types of platforms is all but inevitable. There simply are not enough skilled cybersecurity professionals available to participate in every aspect of the application development and deployment process.

    At the very least, automated vulnerability remediation tools should inform developers of the mistakes being made most often. Over time, the number of instances of those vulnerabilities being discovered should decline as developers realize they are addressing the same issue repeatedly. Once that becomes obvious, hopefully that long-awaited teachable moment that eliminates that particular vulnerability from the application environment is finally at hand.

    — Mike Vizard

  • Government Legislation Aims to Secure IoT

    Government Legislation Aims to Secure IoT

    The U.S. Senate is making moves to protect consumer interests, data, and privacy with regard to the internet of things (IoT). Sens. Mark R. Warner (D-VA) and Cory Gardner (R-CO), co-chairs of the Senate Cybersecurity Caucus, along with Sens. Ron Wyden (D-WA) and Steve Daines (R-MT), recently introduced bipartisan legislation called the Internet of Things Cybersecurity Improvement Act of 2017.

     

    Addressing IoT Market Failures

    According to a fact sheet released by the senators, “While ‘Internet of Things’ (IoT) devices and the data they transmit present enormous benefits to consumers, the relative insecurity of many devices presents enormous challenges. This legislation is aimed at addressing the market failure by establishing minimum security requirements for federal procurements of connected devices.”

    The proposed legislation drives home a new reality for IoT device manufacturers: While development organizations currently decide to invest in cybersecurity using a cost-benefit assessment, they are ultimately liable for the security of their data and systems.

    The U.S. Senate’s Proposal

    The proposed legislation requires vendor commitments:

    • To ensure devices don’t contain known security vulnerabilities when shipped.
    • To ensure proper disclosure of new security vulnerabilities discovered within their devices.
    • To prepare remediation plans for any IoT device where known vulnerabilities have been discovered.

    The Internet of Things Cybersecurity Improvement Act of 2017 is tied directly to federal government procurement of such devices but Sonatype predicts they likely will extend into private-sector guidelines moving forward. While the legislation is clearly aimed at consumer protections and privacy, it also focuses on quality, safety and regulatory standards applied to every other major manufacturing industry (“Thou shall not ship products with known defects“). It’s commonsensical in other manufacturing industries, and now Congress is directing development organizations to apply similar quality standards for the software it develops and ships.

    Certify IoT Devices are Free from Known Security Vulnerabilities

    The legislation specifically calls for vendors selling IoT devices “to provide written certification that the device does not contain, at the time of submitting the proposal, any hardware, software, or firmware component with any known security vulnerabilities or defects.”

    Notification When New IoT Vulnerabilities are Discovered

    Following the purchase of any IoT devices, the government wants the seller “providing the Internet-connected device software or firmware component to notify the purchasing agency of any known security vulnerabilities or defects subsequently disclosed to the vendor by a security researcher or of which the vendor otherwise becomes aware for the duration of the contract.”

    Ensure Remediation Paths are Available

    Protections go even further in the post-sale period, calling for clear remediation paths. The proposed legislation would require “any future security vulnerability or defect in any part of the software or firmware [of the IoT device] to be patched in order to fix or re-move a vulnerability or defect in the software or firmware component in a properly authenticated and secure manner.”

    20 Vulnerabilities Per Application

    Recently, Sonatype released its “2017 State of the Software Supply Chain” report that shares empirical evidence of the number of known software vulnerabilities that ship in applications—IoT or otherwise. The report found that development organizations building software with unmanaged software supply chains release applications with an average of 20 known security vulnerabilities, six of which had a Common Vulnerability Scoring System (CVSS) rating between 7 and 10.

    Sonatype’s report also reveals how national governments, federal agencies and industry associations are taking action to help organizations improve open-source hygiene and application security practices. In the past year, new guidelines have been introduced from the White House, Federal Trade Commission, Department of Homeland Security, Department of Health and Human Services and the Department of Commerce to improve the quality, safety and security of software supply chains, related to IoT devices and any other application development efforts.

    The Tide Has Turned

    While the proposed legislation is still open for debate, there is clear evidence that those once ignorant or turning a blind eye to such cybersecurity issues are now paying attention—and they are preparing to make significant changes.

    The full text of the proposed legislation for the Internet of Things Cybersecurity Improvement Act of 2017 can be found here.

    — Derek E. Weeks

  • Government Asks: What’s in Your Software?

    Government Asks: What’s in Your Software?

    Multiple agencies across the U.S. government are paying closer attention to the software they are buying. More specifically, they want to know what open-source and third-party components were used to build the software applications. For example:

    Similar moves by the National Institute of Standards and Technology (NIST), Underwriters Laboratories (UL) and the U.S. General Services Administration’s (GSA) 18F Group have also been noted over the past year. The common thread among these initiatives is a need for a Software Bill of Materials.

    According to wikipedia, a “Software Bill of Materials (software BOM) is a list of components in a piece of software. Software vendors often create products by assembling open source and commercial software components. The software BOM describes the components in a product. It is analogous to a list of ingredients on food packaging.”

    What’s in Your Software?

    Nowadays, that question is not difficult to answer. Where software applications of the past were coded from scratch—each one being like a unique snowflake, today’s applications are assembled with reusable open-source and third-party components.  With 80 percent to 90 percent of an application now built from open-source and third-party components, it is easy for organizations to quickly produce a Software Bill of Materials.

    The Same Rules Apply to Software

    You don’t want to purchase spoiled food, buy a car with defective airbags or have a relative receive a defective pacemaker. Modern society would not accept products built this way. The same rules apply to software.

    Recent analysis of 25,000 applications that revealed 6.8 percent (about 1 in 16) of components used by development teams included a known security defect. The defects are known security vulnerabilities in open-source and third-party components used to build the applications. With known defect rates in software manufacturing so high compared to other manufacturing industries, it’s no wonder government agencies are paying more attention.

    The Same Guidelines Apply Outside of the Government

    Industry organizations including the American Bankers Association (ABA) and the Energy Sector Control Systems Working Group (ESCSWG), along with private sector organizations that include Exxon and The Mayo Clinic, are also mandating use of a Software Bill of Materials. Producing a Software Bill of Materials will soon be a common practice across development organizations, just as it is across other manufacturing industries.

    A bill of materials provides a useful ingredient list. For some organizations, that ingredient list serves to inform businesses and government organizations that they are not buying products with known defective parts. Other organizations will rely on the bill of materials as a point of record for what parts were used within a released software application—again, another common practice in manufacturing.

    Just yesterday, I received a recall notice from Toyota informing me that my car had a known defective Takata airbag. Toyota knows exactly what part was used in the car it sold me 10 years ago and tracked me down. The company informed me that it is working on a remedy to fix or replace that defective part in my car.

    Imagine if application developers, using a Software Bill of Materials, could do the same thing as Toyota. Imagine the next OpenSSL heartbleed-like vulnerability is announced tomorrow. How many software practices could immediately identify if they used the specific version of that flawed component in their application. How many of those organizations could track that component down in seconds? How many of them would offer to remediate that critical defect in a timely manner?

    It’s Not Just Rules—It’s Software Supply Chain Optimization

    One of my favorite quotes from “The Phoenix Project” (a must-read novel about DevOps) goes like this: “You win when you protect the organization without putting meaningless work into the IT system. And you win even more when you can take meaningless work out of the system.”

    An average application includes 106 open-source and third-party components. If you select the best components, you can build the best software. Use known defective components and you are introducing waste, rework and technical debt into the system—a.k.a., meaningless work.

    Producing a Software Bill of Materials can help organizations quickly identify what parts have been used in an application—good or bad. In a recent discussion with VMTurbo’s Chief Architect, Sylvia Isler, she noted: “Zero tolerance for risk is also why some customers require us to provide proof that our applications do not contain hidden security or licensing vulnerabilities.” Not only does their zero-tolerance policy improve customer satisfaction, it also helps them by removing meaningless work from their system. Customers are happy and so are their development teams.

    screen_shot_2016-07-29_at_4-53-51_pm

    A Free Software Bill of Materials in 15 Seconds

    There are companies that provide services to help users create a Software Bill of Materials. Sonatype, for example, offers the service for free service. Analyzing a typical application might take 20 seconds, and produces a list of all open-source components identified by their name, version and license type, and listing known security vulnerabilities, adoption rates, age and other attributes.

    If governments and customers are paying closer attention to what’s in the software they are buying, it might just be time to figure out what’s in the software you are building.

    — Derek E. Weeks