devopsy.kinsta.cloud

Tag: third-party code

  • The Risks of Shadow Code

    The Risks of Shadow Code

    As the economy struggles to recover after the last two years of the COVID-19 pandemic, we have all learned a thing or two about supply chains—and what happens when they break down. But many people do not realize that modern websites also have digital supply chains, third-party ones that can be compromised in myriad ways. And just like the disruption of the physical supply chain affects things like pricing, availability and inventory, digital supply chains found on today’s websites play a big role in critical areas like site performance, customer experience and overall analytics. As a result, businesses today need to be aware of how the digital supply chain can introduce significant risk, especially when third parties do not adhere to their own set of stringent standards around security and compliance.

    According to a recent study by Source Defense, organizations that collect and use sensitive data—such as health care, finance, travel and online retailers—need to strengthen their focus on third-party risk management. As a result of mandates like GDPR and PCS DSS, these companies are now bound by compliance requirements to ensure their client-side threats are avoided and/or mitigated. This effort means recognizing more than just how to protect private data—it means understanding the properties of malicious code known as “shadow code” on modern websites and how it generates risk from dynamic and unpredictable scripts. Companies dealing in data today need to be aware of the different ways shadow code can affect their security, as well as the productivity and integrity of their DevOps teams.

    Third-Party Scripts and Shadow Code

    Shadow code refers to code that is baked into an application without proper vetting by the website’s IT department. This malicious code thrives in the cloud landscape, primarily because it allows for ease of deployment through CI/CD automation.

    When a web page calls in a third-party script, it loads directly into the browser from a remote server, which means general security controls such as firewalls and network monitoring tools are bypassed. And if one of these scripts has been compromised by a bad actor, shadow code can be embedded within. Sometimes these scripts include open source software that hasn’t been tested well—or at all. Other times, the code may be pulled from another layer of the organization where malicious code is hiding.

    Shadow code presents an array of threat opportunities, including the ability to mount an attack through digital supply chain partners. When these compromised scripts are used to steal data, redirect web traffic,or any other malicious activity, a clear path is essentially created into thousands of different websites, in almost every industry that collects data or deals in digital transactions. When a third-party script with shadow code enters a system, it gains the ability to:

    • Record keystrokes
    • Redirect visitors to malicious websites
    • Monitor clicks and track website activity
    • Change content on websites, including images and text
    • Steal credentials, such as personal logins and social security numbers

    As we know, these digital activities can lead to big consequences, like data breaches, fraud, theft, compliance violations, loss of reputation and hefty fines. Although code reviews can provide some software quality assurance, the process is not effective against shadow code, mostly because these scripts are constantly altered by third-parties. And when the threat is underestimated and unattended, these malicious scripts have the potential to permeate every area of a company’s web property.

    Because the benefits of using these types of third-party scripts are considerable, it can be hard to find a modern enterprise or agency that does not rely on at least a few to run web applications. In fact, many enterprises and government agencies today are running third-party scripts on every page of their sites. Even though these organizations are technically not responsible for this harmful code, regulators can (and do) hold web property owners accountable for any digital maleficence on their sites.

    DevOps Teams and Shadow Code

    Websites can provide rich experiences to visitors largely because developers use client-side JavaScript to improve the look and feel of these digital properties—all without the need for ongoing maintenance. Today, DevOps professionals can access vast libraries of these free and low-cost scripts from many different sources, such as allied coder groups, open source organizations, social media companies, web analytics firms, content delivery networks and more.

    But the reality is, code libraries accessed by DevOps teams are not always secure or trustworthy. Considering these packages often contain code from fourth and fifth parties, DevOps folks face the unavoidable possibility of tainted code—hard to identify and dangerous to use. In fact, the Source Defense report revealed that one in four scripts represented fourth- or fifth-party code, on average. Because developers tend to focus on keeping their code updated and as capable as possible, they often pull from the dynamic library from their repository. If there is a CI/CD process happening, DevOps teams will pull their library from that point. This is where shadow code introduces new vulnerabilities for developers.

    Shadow code also jeopardizes the integrity of DevOps work. Most developers take pride in what they do and are not interested in creating unsecure or low-quality code—not purposefully, anyway. And given that speed, productivity and constant innovation are all business goals for DevOps teams, it’s important to recognize how problematic shadow code can be for those in the business of building secure and high-quality software.

  • How Third-Party Security Assurance Enhances DevSecOps

    How Third-Party Security Assurance Enhances DevSecOps

    Enterprises are constantly trying to do more with less today, and do it faster to gain competitive advantages and grow revenue. Nowhere is this more prevalent than in their internal software development processes. The movement to third-party or external sources of code is a natural reaction to “faster” release cycles. However, this need for speed can have unintended downstream security consequences for application development teams.

    As cybercrime has grown parallel to the explosion of digital processes in many enterprises, “security by design” needs to go from a nice-to-have concept to a hard reality. This is the reason DevSecOps has gone from buzzword to practice for many development teams. Implementing a software security assurance program, which embeds security as part of the coding and assembly process rather than a separate, after-the-fact quality testing function performed by security staff, is vital to limiting the cost of fixing vulnerabilities and preventing data breaches.

    Software Attacks are a Growing Problem

    One of the recent and most high-profile cybercrime incidents involved hackers using the SolarWinds software platform as a launching pad to breach companies. With threats specifically targeting software on a growth curve, organizations need to secure both the software they develop and that which they acquire from suppliers. This often includes a lot of reused code picked up from vendors and open source libraries that offer the building blocks for software and applications to help developers work faster and cheaper—but with a potential security cost.

    Maintaining software security has become more complicated as enterprises rely more on third parties for the components to develop software faster and cheaper and keep up with digital disruption. The share of code developed in-house for enterprise software has dropped from 43% to 38% in the last five years, while the use of commercial and open source software has grown in its place. Rather than rely on custom code, many developers are leveraging open source components or API libraries to build applications. Some software vendors provide application libraries that can have third-party components purchased by that vendor for their customers.

    Leaning on third-party code can leave software open to abuse, as developers have less visibility into the content of the components they use as the building blocks of their programming. Some vendor libraries get reused by the vendor for different applications, and some use open source components in their code; a developer may be using third- and fourth-party code from who-knows-what source. Vulnerabilities can be hiding many layers deep in the code, and unless developers know the source, they are difficult to detect.

    This is where a well-established software security assurance program can reduce the risk of cybersecurity incidents and the impact of security weaknesses. It protects users and the enterprise by establishing cybersecurity practices, fulfills the organization’s risk management and compliance requirements and offers the C-suite visibility into the process.

    A Checklist for Software Security Assurance

    A well-organized security assurance program ensures that security requirements have been established for the software and the software development process and that any software deployed is free from vulnerabilities. If any are found, it also establishes remediation steps to handle them.

    Some important practices:

    ● Trust but verify: Ensure that a security evaluation has been performed for the software throughout the software development life cycle (SDLC). Proactively validate the security and integrity of software code and provide results identifying any vulnerabilities found and assign remediation steps to correct them before release into production.
    ● Know what’s in the software: Since many developers and software vendors rely on open source and third-party code more frequently, it’s more important than ever to know what those components are and where they come from. Software security
    assurance should include the software bill of materials (SBOM) for any open source code and third-party components.
    ● Put it in writing: Produce documented proof, such as the SBOM mentioned above, and generate a vulnerability report proving the integrity of the software. If vulnerabilities are found, determine the cybersecurity risk and the potential impact based on the Common Vulnerability Scoring System (CVSS) score, an industry standard, to guide remediation.

    A good software security assurance program makes sure that each software review or audit includes an evaluation of the security requirements for the enterprise. These can vary by industry—and even within the organization—based on which function the software is running. A program running mailing lists for a power generation company is not as mission-critical as the software running the power grid.

    With all industries in the crosshairs of cyberattackers, an effective and diligent software security assurance program will make it harder for them to find a back door and can help keep your organization safe.

  • SaltStack Updates Enterprise IT Automation Framework

    SaltStack Updates Enterprise IT Automation Framework

    SaltStack has partnered with Tenable.io to make it possible to pull vulnerability data into the enterprise edition of its namesake IT automation framework.

    In addition, version 6.2 of SaltStack Enterprise now integrates with the IT operations analytics platform from Splunk to make it possible to configure the Splunk Universal Forwarder to index and analyze events generated by the SaltStack framework.

    The SaltStack Comply compliance management module has also been updated to include content for Windows Server 2012 and Windows Server 2019 platforms that has been certified by the Center for Internet Security (CIS).

    Finally, SaltStack Enterprise 6.2 optimizes communications between the Salt Master and the SaltStack Enterprise Operations Framework by adding an intermediate SQLite database layer to queue events. SaltStack says IT organizations should see 20 times-plus improvement in event processing throughput. SaltStack has also added the ability to forward SaltStack events to any Salt Returner, such as a SQL database or local file, to improve performance and maintain high availability.

    Mehul Revankar, a senior product manager for SaltStack, said with this update to the enterprise edition of its open source framework the company is leveraging partnerships to enable IT systems to create closed-looped systems. For example, vulnerabilities identified by Tenable.io now can be automatically remediated using SaltStack Enterprise.

    Revankar said the goal is to make it easier for IT teams to create an IT process that can be automated at the push of a button. As IT environments become larger and more challenging to manage, IT organizations will need to automate more processes at scale, he said. To achieve that goal, SaltStack is simplifying the process to connect to a wider range of third-party platforms that house the type of data required to automate a closed-loop process.

    Naturally, organizations that have embraced DevOps principles are at the forefront of IT automation. Revankar said that as teams of IT professionals converge to drive DevOps and DevSecOps processes, the greater the willingness to employ IT automation frameworks becomes. The goal is to automate as many processes to inject a level of agility that serves to accelerate the rate at which applications are deployed and updated. The challenge organizations have always faced in IT automation is the time it takes to integrate an IT automation framework with relevant data sources.

    Revankar also noted resistance to IT automation among rank-and-file members of the IT operations team is declining as the number of applications that need to be managed increases. Most organizations can’t find or afford to retain enough IT personnel to manage IT operations at the level of scale now required. As such, the need to automate as many rote IT processes as possible has become apparent to all. That’s especially critical in the case of vulnerability management, where the amount of time it takes to patch an application directly correlates to a specific level of risk.

    There is, of course, no shortage of options these days when it comes to IT automation frameworks. In fact, the decision concerning which IT automation framework to employ now has as much to do with the number of sources that framework can pull relevant data from as much as it does the reliability of the automated processes that framework enables.

    — Mike Vizard

  • Securing Third-Party and Open Source Code Components: A Primer

    Securing Third-Party and Open Source Code Components: A Primer

    The increasing popularity of open source code continues to be a boon for developers across the industry, allowing them to increase efficiency and streamline delivery. But there are security risks to be considered when leveraging open source and commercial code components, as each carries with it a significant risk of becoming the enemy within, creating a vulnerability in the program it helps build.

    Sacrificing Security for Ease of Use

    While the many benefits of open source have been well-touted, the sheer prevalence of code components (open source and commercial) across industries is underestimated. CA Veracode recently found that 83 percent of developers use code components to build web applications, with the average number of components per application at a whopping 73.

    Considering the fact that the vast majority of developers build applications with code components, the number of those familiar with the risks of doing so is startlingly low. A mere 52 percent of companies reported they provide security fixes to components when new security vulnerabilities are discovered. Despite an average of 71 vulnerabilities per application introduced through the use of third-party components, only 23 percent reported testing for vulnerabilities in components at every release.

    Furthermore, only 43 percent of developers reported being aware of the industry-accepted OWASP recommendations for preventing the use of components with known vulnerabilities.

    Where Does Responsibility Lie?

    One clear issue in this software development practice is that responsibility for securing code seems to fall on everyone—and, sometimes, no one. Forty-four percent of respondents claimed that developers are responsible for the continued security of code components, while 31 percent reported that they expect security to handle this task.

    This lack of preparedness and miscommunication leaves the door wide open for bad actors to swoop in and take advantage of vulnerabilities that could so easily be fixed.

    How, then, can teams ensure the security of applications built with code components? The solution lies in three key steps:

    • Start with education: Software development teams must have the tools and training necessary to ensure the code they write is secure. Educating developers on the risks associated with open source and commercial code components is a start, but prioritizing security training and ongoing education is the key to long-term success. Tapping the security team to lead trainings for their developer colleagues is a good way to embrace peer knowledge-sharing and break down silos between the two teams.
    • Introduce clear processes: To alleviate miscommunication and confusion, organizations must implement clear processes for secure software development. Knowing what an application is built of is the first step, as teams can’t secure what they don’t understand. This may seem obvious, but CA Veracode found that only half (53 percent) of organizations keep an inventory of components. Code components should be thoroughly vetted before being worked into an application and then should be added to a working inventory. Managers should be sure each part of the maintenance process has a clear owner on the team so responsibility is always clear. Consistent testing and patching are also best practices when it comes to security.
    • Drive innovation with DevSecOps: All of this comes back to integrating security into the entire software development life cycle (SDLC) and implementing DevSecOps, because a team that operates in silos will never be able to push out secure code. The development, operations and security teams each provide their own unique and critical contribution to the software development process, and combining forces will result in the best possible product.

    While taking the time to secure applications from the perils of code components may slow down development in the short term, safeguarding your organization and its software assets is invaluable in the long term.

    — Pete Chestna