devopsy.kinsta.cloud

Tag: vulnerability

  • JFrog Survey Surfaces Raft of DevSecOps Challenges

    JFrog Survey Surfaces Raft of DevSecOps Challenges

    A global survey of 1,224 security, development, and IT operations professionals published today by JFrog finds that 60% typically spend four days or more remediating application vulnerabilities in a given month.

    JFrog security researchers, however, noted it’s probable most of those vulnerabilities are not as severe as they have been rated. After analyzing 212 vulnerabilities, the JFrog Security Research team downgraded the severity of 85% of the vulnerabilities rated as critical and 73% of one rated as high.

    JFrog researchers also found that 74% of the reported common vulnerabilities and exposure (CVEs) with high and critical CVSS scores assigned to the top 100 Docker Hub community images weren’t actually exploitable.

    Only 17% of the vulnerabilities analyzed enabled remote code execution, compared to 44% that could enable a denial of service (DoS) attack, the researchers noted.

    Stephen Chin, senior director for developer relations for JFrog, said that analysis suggests organizations are arguably spending too much time on application security at the expense of productivity. Tools that generate alerts based on severity rather than also rating exploitability are creating too much noise simply because they don’t provide enough contextual analysis, he added.

    Conversely, in the absence of that level of detailed analysis, it’s possible a low-level vulnerability that might be especially severe in a specific IT environment, also known as a false negative, might not be further investigated, noted Chin.

    Security concerns, however, also limit innovation, with 40% of the survey respondents noting that because of security reviews, it typically takes a week or longer to get approval to use a new package/library.

    Nearly half of IT professionals (47%) say they use between four and nine application security tools, with 90% reporting they use some type of tools that rely on machine learning algorithms or other forms of artificial intelligence (AI) to scan, identify and remediate vulnerabilities.

    Less than a third (32%), however, work for organizations that use AI to write code. That relatively low level suggests many organizations are still not comfortable with the quality of the code generated, noted Chin. Of course, individual developers may still be using those tools without approval.

    More than half (53%) say their organization uses between four to nine programming languages, with nearly a third (31%) reporting they use 10 or more.

    The most frequently used tools are static application security testing (61%), dynamic application security testing (58%), software composition analysis testing (56%), and application programming interface (API) security (56%).

    A full 89% said their organization has adopted a security framework such as OpenSSF or Supply-chain Levels for Software Artifacts (SLSA).

    Finally, the survey finds little consensus concerning when to run security scans, with 42% saying it’s best to perform security scans as code is being written versus 41% that prefer to perform scans on new software packages before installing them. A total of 41% said runtime is the least desirable place to run scans. More than half (56%) said their organization applies security scans at both the code and binary scanning levels.

    The degree to which DevSecOps best practices are being adopted will naturally vary from one organization to the next. The challenge is to prioritize remediation efforts in a way that enables developers to spend more time writing, for example, business logic versus patching vulnerabilities are not actually a material threat. In that context, the quality of the vulnerability analysis generated by scanning tools matters because of the unnecessary toil that might be eliminated, noted Chin.

    It may be a while before most organizations are able to strike the right balance when it comes to DevSecOps, but as a greater appreciation for the nuances of application security continues to take hold, the less stress there should hopefully one day be for all concerned.

  • Sonar Adds Secrets Detection to Code Analysis Portfolio

    Sonar Adds Secrets Detection to Code Analysis Portfolio

    Sonar has added a secrets detection capability to its portfolio of tools for analyzing code and DevOps workflows.

    Designed to be applied to both finding secrets in code repositories and as applications are developed using an integrated development environment (IDE), this capability is being added to SonarLint, SonarQube and the managed SonarCloud service to identify, for example, passwords, application programming interface (API) keys, encryption keys, tokens, database credentials and other private information.

    Sonar co-CEO Olivier Gaudin said the goal is to eliminate secrets that are accidentally or maliciously stored in source code to improve software supply chain security.

    While it’s important to discover secrets in codebases, Sonar is making a concerted effort to make it simpler for developers to discover secrets before they find their way into a codebase that is one step away from a production environment, noted Gaudin. The SonarLint static analysis tool the company provides can now discover secrets in microseconds using the syntactic and semantic analysis engines the company has now extended, he added. No developer is going to wait five to 10 minutes for a code scan to be completed, said Gaudin.

    A Learn as You Code tool also explains how each secret found in a code segment poses a security risk. The overall goal is not only to remove secrets but, ultimately, reduce the number of instances where secrets are discovered in code, said Gaudin.

    Most organizations today are at varying stages of embracing DevSecOps best practices to improve software supply chain security. It’s not clear how readily secrets management is being embraced as part of those modernization efforts, but as cybercriminals routinely scan for application secrets stored in clear text that can be used to compromise application security, the need to encrypt secrets becomes a higher priority.

    There is, of course, no shortage of tools for detecting secrets. Sonar is now simply making a case for managing secret detection as part of a larger effort to reduce vulnerabilities in code that cybercriminals can exploit. That approach should help reduce the total cost of securing a software supply chain at a time when forthcoming regulations are going to make organizations that deploy software more accountable for application security.

    In the meantime, thanks to the rise of generative artificial intelligence (AI), the volume of code that needs to be scanned will likely exponentially increase. The issue with general-purpose AI platforms such as ChatGPT is they were trained using code of varying quality that often contains vulnerabilities that are now sometimes incorporated into the code they generate. On the plus side, however, many developers have little to no application security expertise, so it’s just as feasible that ChatGPT will create more secure code than a human developer. Regardless of how the code was created, however, no one will know for sure how secure it is without scanning it first.

    Hopefully, as AI progresses, the quality of the code being generated will only continue to improve. Until then, DevOps teams should continue to assume all code is suspect until proven otherwise.

  • Vulnerability Management for DevOps Teams: A Practical Guide

    Vulnerability Management for DevOps Teams: A Practical Guide

    Vulnerability management is a process that includes the identification, categorization, prioritization and resolution of security vulnerabilities in software systems. It involves a continuous cycle of protection to ensure that your digital assets are secure and your operations are running smoothly.

    With the rapid evolution of technology, fast-moving cloud-native systems and evolving cyber threats, it’s critical to stay ahead of the game. The goal is to close the gap between the discovery of vulnerabilities and their resolution, thereby minimizing the window of opportunity for potential attacks.

    Vulnerability management is not just about finding and fixing vulnerabilities. It’s also about understanding the nature of the vulnerabilities and the potential impact they could have on your network and systems. This understanding informs the prioritization process, helping teams decide which vulnerabilities need immediate attention and which ones can be addressed later. See this blog post for an in-depth review of vulnerability management.

    Why is Vulnerability Management Important for DevOps Teams?

    With the DevOps approach, development and operations teams work together throughout the software life cycle. This collaboration results in faster development times and more reliable software. However, the fast development cycle also introduces new security challenges. This has given rise to the DevSecOps paradigm, where developers, operations teams, and security experts collaborate during all stages of the development lifecycle.

    Here are a few reasons vulnerability management is a critical part of DevSecOps practices:

    Early Detection of Vulnerabilities

    DevOps teams are under constant pressure to deliver high-quality software quickly. However, the speed of delivery should not compromise the security of the software. Vulnerability management helps DevOps teams identify vulnerabilities early in the development process. This early detection allows teams to address security issues before they become serious problems.

    Early vulnerability detection is not just about finding vulnerabilities; it’s also about understanding the potential impact of those vulnerabilities. It involves analyzing the vulnerabilities to determine their severity and the risk they pose to the system. This analysis informs the prioritization process, ensuring that the most critical issues are addressed first.

    Building Continuous Security Into CI/CD Pipelines

    Integrating vulnerability management directly into continuous integration/continuous deployment (CI/CD) pipelines is essential for maintaining continuous security. CI/CD pipelines automate the steps in software delivery, from code integration to deployment, ensuring faster and more consistent releases. By embedding vulnerability management into these pipelines, DevOps teams can automatically scan for and address security vulnerabilities at each stage of the software development life cycle.

    Incorporating vulnerability management tools into CI/CD pipelines allows for automatic scanning of code repositories, container images, and even infrastructure-as-code (IaC) configurations for known vulnerabilities. This integration means that any security issues are identified as soon as code is committed or containers are built, not just at the deployment stage. The advantage of this approach is twofold: It reduces the risk of deploying vulnerable software, and it allows developers to fix issues in their context of development, making the process more efficient.

    Cost-Effective Development and Operations

    Implementing vulnerability management can lead to cost savings for DevOps teams. By identifying and resolving vulnerabilities early in the development process, teams can avoid the high costs associated with fixing security issues after the software has been deployed. In addition, vulnerability management can help prevent costly security breaches that could damage the company’s reputation and result in financial loss.

    Moreover, vulnerability management can contribute to more efficient operations. By systematically managing vulnerabilities, teams can avoid wasting time and resources on low-priority issues. Instead, they can focus their efforts on addressing the most critical vulnerabilities.

    Enhancing Cross-Team Collaboration

    Vulnerability management can also enhance cross-team collaboration within the DevOps environment and between DevOps and security teams. By providing a clear framework for identifying, categorizing, prioritizing and resolving vulnerabilities, it fosters a shared understanding of security issues among team members. This shared understanding can facilitate communication and cooperation, ultimately improving the software product’s security posture.

    Strategies for Integrating Vulnerability Management Into DevOps Processes

    Adopt a ‘Shift-Left’ Approach

    The ‘shift-left’ approach is a strategy that involves shifting the security measures to the early stages of the DevOps pipeline. Traditionally, security checks and vulnerability assessments were conducted toward the end of the development cycle, often leading to late discovery of security flaws and vulnerabilities.

    By shifting these security measures to the left, i.e., to the earlier stages of the development cycle, DevOps teams can catch and fix security vulnerabilities early on. This approach aligns well with the DevOps philosophy of early error detection and continuous improvement.

    Automation of Vulnerability Scanning and Detection

    Automation is at the heart of DevOps. It allows for rapid, reliable and consistent processes, freeing up the team to focus on what they do best – delivering quality code and features. Automation should also extend to vulnerability management.

    Automating vulnerability scanning and detection means integrating security tools into the DevOps pipeline that can automatically scan the code, detect vulnerabilities and even suggest fixes. This approach ensures that security checks are not skipped or forgotten and that vulnerabilities are dealt with promptly.

    Security as Code

    Another strategy for integrating vulnerability management into DevOps processes is embracing the principle of security-as-code. This principle treats security infrastructure and configurations as code, allowing them to be part of the DevOps pipeline.

    By adopting security-as-code, DevOps teams can ensure that the security configurations and infrastructure are always up-to-date and follow the best practices. Like the rest of the code, security configurations can be version-controlled, reviewed, tested and automatically deployed.

    Collaboration Between Security and DevOps Teams

    One of the key tenets of DevOps is collaboration between different teams. In a DevSecOps paradigm, this collaboration extends to the security team as well. Integrating vulnerability management into DevOps processes fosters close collaboration between the security and DevOps teams.

    The security team can provide valuable insights into the security landscape, vulnerability management tools and best practices. On the other hand, the DevOps team can ensure that these insights and tools are integrated into the DevOps pipeline.

    Continuous Monitoring and Feedback Loop

    Continuous monitoring is crucial for effective vulnerability management. Continuous monitoring ensures that the security state of the system is always known and that any changes or vulnerabilities are promptly detected. The feedback loop ensures that the insights gained from monitoring and vulnerability assessments are fed back into the development process, leading to continuous improvement in security.

    Regular Training and Awareness

    Finally, regular training and awareness are crucial for integrating vulnerability management into DevOps processes. DevOps teams should be trained in security best practices, threat landscape, and use of vulnerability management tools.

    Regular training ensures that the team stays up-to-date with the latest security trends and vulnerabilities. Awareness sessions can help the team understand the importance of security and vulnerability management, encouraging them to take an active role in securing the system.

    Conclusion

    In conclusion, integrating vulnerability management into DevOps processes is not only possible but crucial for secure and reliable systems. Adopting a shift-left approach, automating vulnerability scanning and detection, embracing security-as-code, fostering collaboration, implementing continuous monitoring and feedback and ensuring regular training and awareness are some of the strategies that can help achieve this integration. 

    Remember, vulnerability management is an ongoing process that requires commitment, collaboration and continuous improvement.

  • Tanium Uses SBOMs to Automate Vulnerability Remediation

    Tanium Uses SBOMs to Automate Vulnerability Remediation

    Tanium this week added the ability to detect libraries and software packages with known vulnerabilities within a software bill of materials (SBOM) manifest that can then be used to automate remediation of endpoints running vulnerable code.

    Pete Constantine, senior vice president of product management for Tanium, said the Tanium Software Bill of Materials (SBOM) module provides IT teams with both the ability to discover where vulnerable code is running in real-time and automatically apply any required software patch.

    The Tanium SBOM tool examines the contents of individual files wherever they reside in IT environments to make it simpler to immediately discover where, for example, vulnerable instances of the Log4j log management software or OpenSSL software for securing communications are running. Today many IT teams are spending weeks trying to track down every potential instance of code each time a new vulnerability is discovered.

    Once those vulnerabilities are discovered, IT teams can then opt to use a Tanium Patch tool to remediate vulnerabilities or use other Tanium management tools to kill specific processes or uninstall applications, noted Constantine.

    Awareness of the need for SBOMs to secure software supply chains has increased sharply in the wake of a series of high-profile cybersecurity breaches. However, few organizations have the tools in place to operationalize the data collected in SBOMs that are essentially little more than a list of components employed to build an application. The goal is to enable IT teams to decide whether to go ahead and deploy an application based on the level of threat the vulnerabilities included represent.

    It’s unlikely that vulnerabilities will ever be completely eliminated from applications running in production environments, but it’s clear there is a need to be able to quickly identify issues based on the level of severity any vulnerability represents. The trouble is that an SBOM is only the first step toward achieving the level of remediation automation that is required to address vulnerabilities discovered in applications after they have been deployed.

    Hopefully, all the focus on securing software supply chains will lead to a narrowing of the divide that has historically existed between cybersecurity and application development teams. Developers still need to create patches to fix issues, but overall the number of vulnerabilities that find their way into production environments should decline as more organizations embrace DevSecOps best practices before applications are deployed.

    In the meantime, however, given how much developers today reuse code, the odds are good multiple vulnerabilities have already been widely propagated across an application environment. In fact, the amount of technical security debt that organizations face today is simply staggering when considering the total number of potential vulnerabilities that need to be remediated. In the absence of IT automation capabilities, it might take the better part of a decade to resolve all those vulnerabilities.

    On the plus side, however, the tools and platforms required to automate remediations are now integrated with SBOMs that, at the very least, make pinpointing where vulnerabilities are located easier. The challenge now is defining a set of end-to-end processes that make fixing all those vulnerabilities a much less arduous task for all concerned.

  • Open Source: Is Your DevOps Org Vulnerable to an Equifax-Style Hack?

    Open Source: Is Your DevOps Org Vulnerable to an Equifax-Style Hack?

    More than half of the Fortune 100 could be at risk of falling prey to the same kind of hack that caused devastation at Equifax last year, and it all comes down to poor open source component governance.

    A new report out from Fortune reports that in the year after Apache Software Foundation issued an update to its Apache Struts framework to fix a well-known and critical deserialization vulnerability, more than 10,000 organizations downloaded the vulnerable version instead. Among those were 57 percent of the Fortune 100, according to numbers provided to Fortune by Sonatype.

    The vulnerability is best known to have triggered the catastrophic breach at Equifax in 2017 that exposed the records of 148 million people. It’s a doozy of a flaw—a command injection vulnerability that allows for unauthenticated remote code execution—the kind of opening that gives attackers to gain a powerful foothold in affected systems.

    “Seven months should be enough time for organizations to install the necessary patches and it’s unfortunate that so many still choose to download the older vulnerable versions,” said Nick Bilogorskiy. “There is really no excuse for this.”

    This news should be sobering to DevOps organizations. Increasingly, they’re turning to an assembly-focused mode of software delivery that relies heavily on open source components rather than developers reinventing the wheel with new code. It offers a wake-up call for DevOps organizations to get serious about tracking and securing the third-party code they use.

    In a recent DevSecOps survey conducted by 451 Research on behalf of Synopsys, 40 percent of organizations don’t perform any kind of software composition analysis on their software. That’s problematic, because it means that organizations often don’t know when vulnerable open source components such as Apache Struts are woven into their code base.

    More disconcertingly, even fewer organizations have systems in place that can actually control when, where and what open source components are used within their software development. According to a different DevSecOps survey conducted by Sonatype, 62 percent of organizations don’t have any meaningful controls over which components are in their applications.

    It’s a disconcerting statistic, considering the sheer volume of open source component use in development today—whether in DevOps shops or not. In a talk titled, “We are ALL Equifax” at the DevOps Connect event held at RSA conference last month, Derek Weeks highlighted the fact that open source component download requests have increased 87 times in the last 10 years.

    “The growth rate and consumption volume is massive. And it’s coming into your organization,” Weeks told the audience. “And as a result of this behavior the applications your developers are building are now 80 percent to 90 percent open source components—built from code you did not write from scratch.”

    Sonatype’s survey shows that almost 1 in 3 organizations this year suspect or have verified that they’ve suffered from a breach related to open source components in the last 12 years.

    — Ericka Chickowski

  • Sleep easy: release automation reduces DevOps security threats

    Sleep easy: release automation reduces DevOps security threats

    Sleep easy: release automation reduces DevOps security threats

    “Devops reigns”. “DevOps redefines the way services are launched and managed”. Just two of the recent headlines from the sea of coverage on DevOps. It’s a reasonable argument. The software development methodology emphasizes communication and collaboration between software developers and other IT professionals, and is quickly gaining ground as organizations see a way to launch services faster and improve operations performance. The current DevOps talent shortage also points to Fortune 1000 companies waking up to the difference DevOps can make.

    Here’s the catch. While DevOps appears the master and commander of faster feature releases, it also has the potential to expose software vulnerabilities and security threats in your production environments. We all know that assembling existing code is more efficient than rewriting it from scratch, for example. And when assembling applications from libraries, developers typically use the latest version of that code, assuming it is likely to have less bugs.

    However, new releases can open up new security vulnerabilities. Take the Spring Framework, for instance, a Java platform that provides comprehensive infrastructure support for developing Java applications. According to Joshua Corman, CTO of Sonatype, 81 of the 85 versions of the Spring Framework have known vulnerabilities.

    Software and security vulnerabilities can also rise to the surface unless there is an audit of the production software for security defects. Developers can easily pick up any code they choose without identifying the source or what they did with it. Speaking at the RSA Security Conference, David Mortman, chief security architect at Dell Software, explained that when he began software audits at the company, 198 known execution flaws were found in the code base—putting the company and its applications at risk. And this risk is set to do more harm as DevOps is used to develop physical ‘Internet of Things’ products and services.

    Here’s another fact to put the issue of security into context. Organizations collectively spend $20 billion every year on network security, $10 billion on host security and $5 billion on data security. And you know how much is invested in software supply chain security by all companies? Just half a billion dollars.

    It’s not all bad news though. During the RSA Security Conference, Mortman commented, “A good DevOps process should be implemented using automation tools that can help to track and document updates. DevOps is about change management, process flow and documenting those processes.”

    And automation really is the answer here. It enables you to bring your new products and services to market faster, whilst remaining in control. By automating your application release process, you package the release from your continuous integration tool and securely promote it to the next environment via a reusable work flow. You maintain complete visibility throughout—and there’s no disruption to the business.

    Any software vulnerabilities are quickly identified using role-based access controls: only authorized staff get to promote packages, and only approved packages can move through the lifecycle. Moreover, the automated deployment model ensures you keep track of the code goes on each server and with what configuration settings. And if you are not happy with any aspect of the release, automation enables you to roll back the deployment to its previous state. Finally, comprehensive audit reports help you see who did what and when throughout the entire release process.

    Automation delivers other unique attributes to reduce security risks:

    • Packages and promotion paths so you can be confident that what is deployed is correct
    • Workflows so you have a standard and quality-assured way to consistently           deploy new changes
    • Deployment models to ensure the correct setting and configurations are applied to each environment.

     

    Your development squad is under more pressure than ever to deliver more functionality, faster without disrupting current applications. By automating your application release process, you not only embrace DevOps in full strength, you also gain back control.

    About the Author/ Dr. Chris Boorman

    chris-boormanAs Chief Marketing Officer, Dr Chris Boorman is responsible for Automic’s worldwide marketing.
    Prior to joining Automic, Dr. Boorman served as Chief Marketing Officer for cloud collaboration vendor Huddle, and data integration leader Informatica.  He has over 20 years of experience leading international teams at enterprise companies including SDL, salesforce.com, VERITAS and Oracle. Reach him on Twitter: @CHBoorman

  • Organizational Dysfunction: The original vulnerability

    Organizational Dysfunction: The original vulnerability

    During your teenage years, you may have figured out a way to get a ‘yes’ from your parents by playing off of the responsibility and knowledge gap between them…walking up to your mom and saying something like, “Hey Mom, Dad said he would drive me, can I go out tonight?” and then proceed to your dad and say something like, “Hey Dad, Mom said I can go out tonight and you need to drive me.” There is nothing cleverer than a determined teenager wanting to get his or her way. Such is the case of targeted attackers and the way they play one IT department’s responsibilities off another. This is the grey area where the organizational chart and separation of duty can introduce weaknesses exploited by the more advanced threats we face today.

    You don’t have to look far into your organization to see this at work. The security team does its thing, networking engineers do their thing, and IT operations teams in general all have administrative realms that define functional boundaries as to what they can see and do. To borrow from Colonel John Boyd’s OODA loop, each team has its observation and orientation (OO) process for gaining operational visibility and making decisions, as well as specific decisions and actions (DA) they can execute within their administrative realm or set of capabilities to bring change to their organization. The weakness I’m highlighting in this post is when the decision and action appropriate for a set of observations, and the observations themselves, exist in two separate departments and can be exploited by the attacker.

    To exemplify the problem, let’s begin with the question: Is a distributed denial-of-service (DDoS) attack a security or a network engineering issue? The problem I see most often is that one department will have a precise view into network telemetry for early threat detection, but will not yet have the ability to mitigate or remediate the threat.

    Or how about the situation where credentials for one of your executives are harvested, and now the attacker need not trigger any security events at all in order to carry out an attack. In this situation, the attacker merely needs to log in and plan the next stage of the attack, roaming freely and without suspicion across your network because they are only generating networking traffic. The network team does not act because everything is still available, and the security team does not act because there is nothing being denied in access logs, no firewall violations, and nothing triggered on the IDS/IPS.

    Let me be clear in that I am not saying that everyone has to become an expert in everything; specialization is healthy, but only when it does not compromise communication! In the example of Mom and Dad being played by the teenager, if Mom and Dad had a better communication protocol, the teenager’s tactics would be thwarted. If you look at some of your operational procedures, and start to think like an attacker (or teenager again), I’m sure you will find at least half a dozen communication gaps that a clever attacker could exploit.

    This organizational dysfunction is going to require change that may appear to be radical because the systems that support it are so ingrained. Big analyst firms have defined their technology categories as law and they police them as if you were breaking the law if you dare to create something different – something more cross functional. Some best practices out there are, in my opinion, worst practices because they are so focused on the operational effectiveness of the department, and they leave out other departments or the active threat entirely. Lastly, even some prescriptive compliance requirements force organizations into strict separation of duties, but when implemented, create a broken OODA loop where the ‘OO’ does not connect with the ‘DA.’

    There is an opportunity for DevOps to completely recalibrate how we deliver a cross functional operational unit which is why I took the time to write this article for devopsy.kinsta.cloud.  Through the lens of Boyd’s OODA loop, you can already see the security ramifications because the tempo of DevOps allows the defense to loop at a faster rate than the adversary – the dominant strategy of the OODA Loop.

    I hope this post is a call to action for all you big thinkers. Get creative, get innovative, and do not be afraid to erase some lines and boundaries within your IT organization if it fosters a higher level of communication amongst your teams. Think of your organization like a great band playing live music. All of the performers play different instruments, yet they are listening to one another just as hard if not harder than they are producing sound. They improvise and adapt to one another; monitoring systems are put in place so they can have just enough of each sound in their own ear. This is what effective, cross-functional teams look like.  I’m just going to say it: DevOps is Rock and Roll!

    Oh, and hey, follow me on twitter: @tkeanini