devopsy.kinsta.cloud

Tag: security vulnerabilities

Snyk Adds Second ASPM Tool to Portfolio

Today, Snyk made available an edition of its application security posture management (ASPM) tool for assessing application risks that provides more context into how code has been written and its role within the application environment.

Manoj Nair, chief product officer for Snyk, said Snyk AppRisk Pro leverages artificial intelligence (AI) and machine learning to provide deeper insights into how applications have been constructed. Snyk AppRisk Pro, for example, can trace insecure portions of deployed applications all the way back to the specific code components.

Armed with those insights it then becomes simpler for DevSecOps teams to prioritize their remediation efforts, said Nair.

Snyk originally released Snyk AppRisk late last year and subsequently acquired Helios, a provider of tools for collecting security data from runtime environments via integrations with third-party tools and platforms from Dynatrace, SentinelOne and Sysdig, last January. That capability has now been integrated into Snyk AppRisk Pro.

In addition, Snyk AppRisk Pro also adds the ability to scan for secrets in code that cybercriminals might later discover.

Snyk Working With Google

Snyk has been working closely with Google to apply AI to DevSecOps. Most recently, Snyk announced its support for Gemini Code Assist, a tool for generating code using the Gemini large language model (LLM) created by Google. The integration with Snyk helps identify security vulnerabilities in code before applications are deployed. That’s critical because LLMs are trained using examples of code of varying quality from across the Web. As more code is created using generative AI tools, the probability of vulnerabilities in that code is high because the code used to train an LLM is often flawed. In effect, DevSecOps teams need tools that use AI models to identify vulnerabilities created by other AI models.

Hopefully, as generative AI continues to advance the overall quality of the generated code will continue to improve. The next generation of LLMs is being trained using code that has been vetted for quality. That’s crucial because most of the issues that cybersecurity teams usually need to resolve start with mistakes made by developers that cybersecurity teams then need to convince developers to allocate time to fix. Thanks to the rise of DevSecOps best practices, the overall security of software supply chains is improving. The simpler it becomes for developers to identify issues as they write code the more secure applications will become.

Of course, writing more secure code is only one element of the overall equation. DevSecOps teams will also need to continue to scan code after it’s been added to a build and as updates are made to applications already deployed in production environments. It’s now only a matter of time before more stringent regulations are implemented that will require organizations to attain and maintain higher levels of application security.

The challenge, as always, is modernizing legacy DevOps workflows that typically were designed to build and deploy code as fast as possible rather than ensuring application security requirements are being met.

May 1, 2024
OpenSSL Fiasco: What can DevOps Learn? | Elon Fires ‘50%’ of Twitter

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: The OpenSSL project has egg on its face, and half of Twitter’s staff are for the chop tomorrow. (more…)

November 3, 2022
A Security Vulnerability Management Guide
Living in a container-native world is not easy. Containers have a reputation for being a point of entry for security vulnerabilities for many organizations. In 2015, according to a research paper, over 40% of Docker images distributed through Docker Hub had high-risk vulnerabilities; at that time there were more than 95,000 container images hosted on Docker Hub. Today, there are over 3.5 million container images on Docker, and container security is of even greater concern. In a more recent 2020 study by a team of researchers at the Norwegian University of Science and Technology found container image vulnerabilities in certified and popular packages.

This is just one example of one kind of security vulnerability. This article will share an introduction to security vulnerabilities and the role of vulnerability management for containers and other artifacts in a continuous integration and continuous delivery (CI/CD) pipeline.

What is a Security Vulnerability?

A vulnerability is a weakness or flaw present in software. Security vulnerabilities can be present in application dependencies or operating system (OS) packages. Common vulnerabilities include missing data encryption, buffer overflows, missing authentication for critical functions and insecure interactions between software components.

There are different risks associated with different types of vulnerabilities. With critical or high-risk vulnerabilities, an attacker who exploits your software has the potential to seriously impact your organization. Risks associated with data breaches impact not only an organization, but also its end users and customers.

Vulnerability Management Techniques

Vulnerability assessment practices and tools exist to make detecting vulnerabilities simple, accurate and fast. Some of these practices include:
- Penetration testing – Penetration testing, or pen testing, allows you to identify security vulnerabilities by attempting to break into your own systems to identify weaknesses.
- Configuration management – Configuration management involves managing infrastructure configurations and identifying missing patches that leave your software service vulnerable to errors and risks. There are tools that provide infrastructure scanning as-a-service to help detect outdated or misconfigured instances.
- Container and application Scanning – Allows you to detect vulnerabilities in deployable artifacts and running applications. Some available tools for container scanning include Twistlock, Clair and Trivy.
These practices help build solid, repeatable vulnerability management techniques across your security and delivery teams. One way to scale these security practices is through security automation. Security automation is the use of technology that performs tasks with reduced manual assistance. It ultimately enables users to apply security decisions automatically and secure processes to deliver more robust applications and infrastructure.

Security Practices in your CI/CD process

Security automation is a core tenant of DevSecOps. DevSecOps is short for development security and operations, and it describes how organizations deliver and make security decisions and actions within the development life cycle of their valued deliverables.

DevSecOps is a way of continuously integrating security in the software development life cycle. It’s a way of working and thinking so that security is at the forefront of how security teams deliver business value.

One way to enable DevSecOps is through your CI/CD pipeline. Today’s enterprises can use CI/CD to accelerate better software delivery, but with that speed it becomes even more important to enable robust security. Vulnerability scanning improves software security while giving individuals across engineering and product teams accountability for each of the processes these teams own.

Don’t let Security Vulnerabilities Ruin your DevSecOps

This is a simple, basic introduction to security vulnerabilities and the risks they pose for your organization. There are practices and tools for detecting and reducing security vulnerabilities, and finding ways to incorporate those processes into a CI/CD pipeline is a great way to accelerate your DevSecOps.
January 19, 2021
Top 10 Embedded Security Vulnerabilities

Nearly all of detected security vulnerabilities can be attributed to just 10 types. Here, we discuss the most common cybersecurity vulnerabilities and offer guidance on how to mitigate their risk.

Vulnerability 10: Numeric Errors

Numeric errors can refer to several different categories of problems, including wrap around errors, improper validation of array index, integer overflow, incorrect byte ordering and more. A common place for numeric errors is in math calculations and data overflow from an external source.

Vulnerability 9: Cryptographic Issues

Cryptographic issues are weaknesses related to the use of cryptography. This type of vulnerability is often caused by missing encryption of sensitive data, inadequate encryption strength and more.

Vulnerability 8: Code Injection

Code injections effect interpreted environments such as PHP.

Vulnerability 7: Code

This is a catchall vulnerability that can include such things as mismanaging passwords, improper handling of API contracts and code generation issues.

Vulnerability 6: Resource Management Errors

This type of vulnerability refers to a wide range of issues, including improper management of system resources, resource locking and insufficient resource pool.

Vulnerability 5: Improper Access Control

Improper access control is when software does not restrict, or incorrectly restricts, access to a resource from an unauthorized actor.

Vulnerability 4: Improper Input Validation

Improper input validation refers to getting incorrect or missing information from anything that could possibly impact a program’s control flow or data flow.

Vulnerability 3: Information Exposure

Information exposure is the intentional or unintentional disclosure of information that isn’t explicitly authorized.

Vulnerability 2: Access Control

This vulnerability refers to any weakness related to the management of permissions, privileges or other security features.

Vulnerability 1: Memory Buffer Problems

Memory buffer problems occur when software can read or write to locations outside the boundaries of the memory buffer.

How to Prevent Cyberattacks

An effective way to address each of these vulnerabilities is to rely on a static code analysis and static application security testing (SAST) tool. These types of tools analyze your code as it’s being written for potential coding errors, bugs and vulnerabilities. By addressing vulnerabilities earlier in development, you save time and money.

For a more in-depth look at these 10 vulnerabilities and how to best mitigate their potential risk, review the associated white paper.

To read more, please visit: www.perforce.com/blog/kw/common-software-vulnerabilities

January 11, 2021
Synopsys: IoT, ICS More Vulnerable to Security Exploits

A new report shows that internet of things (IoT) implementations and industrial control systems (ICS) are more vulnerable than most to potential zero-day exploits of the open-source protocols, common file formats and APIs they rely on. The report, prepared by vulnerability test firm, Synopsys Inc., is based on 4.8 billion fuzz tests conducted on the company’s customers throughout 2016. The report focuses on six key vertical areas: automotive, financial services, government, health care, ICS and IoT.

To rank the vulnerability of different protocols, Synopsys measured the time it takes between the start of fuzz testing and when a protocol crash is recorded along with how many crashes occurred over longer periods of time. Newer, less mature or proprietary protocols proved to be the most vulnerable. In some cases, time to failure was measured in minutes or even seconds. Fuzz testing is a method of testing code for flaws and security vulnerabilities that involves throwing large amounts of malformed, random data at the system being tested.

Industrial control systems are the most vulnerable of the six areas covered by the report. To a great degree that’s driven by the fact that ICS uses a lot of proprietary or ICS-specific protocols, some of which may not have been tested thoroughly enough. Three of the most vulnerable protocols are IEC-61850 MMS, IEC-104 SERVER and MODBUS PLC. The ICS protocol IEC-61850 MMS failed in just 6.6 seconds.

IoT is the next most vulnerable system. It mixes older, better-tested core IP protocols with newer niche categories such as wireless and ICS. The three most vulnerable protocols for IoT are CoAP Server (failed in 8.5 seconds), CIP and OPC UA.

It’s important for enterprises to prioritize security in their zeal to build IoT solutions. In some cases, Synopsys revealed that security vulnerabilities stemmed from an incomplete or improper implementation of protocols or unpatched code.

“The applicability of IoT across all vertical markets and within enterprises of all shapes and sizes has brought us to an important inflection point,” said Brad Shimmin, service director for IT Technology and Software at GlobalData. “Thanks to ubiquitous and readily accessible APIs, development frameworks and even pre-built but extensible apps, virtually anyone can stand up an IoT deployment with very little experience in the way of application development practices. This will undoubtedly reveal the many dangers inherent in building highly distributed systems—dangers affecting both data and logic.”

Some interesting data from the report: The overall average time to first failure of a protocol was 1.4 hours. When the time to first failure is measured in seconds instead of hours, it indicates a higher potential for criminal exploitation. The most vulnerable protocol tested was the previously mentioned IEC-61850 MMS; the least exploitable was the TLS client, which had an average time to first failure of 9 hours.

Of the vertical areas the report classifies, the two least risky sets of protocols are the ones used by government and financial services. Synopsys attributes this to the more mature aspects of the categories of protocols used by these industries. They had fewer overall failures and longer test times to their first failure. It would take black hats a lot longer to fuzz them into vulnerability.

— Scot Finnie

August 21, 2017
Sonatype Report Spotlights Software Supply Chain Issues

Most application developers today don’t write much raw code. Rather, applications developed today are created mostly by combing various modules and widgets to create a custom application. But currently there is little oversight being applied to the provenance of application components, especially when it comes to open-source software.

The third annual State of the Software Supply Chain Report published by Sonatype, a provider of tools for managing software supply chains, finds that the amount of time it takes for open-source projects to address vulnerabilities is considerable. The report states that only 15.8 percent of open-source software projects actively fix vulnerabilities, resulting in an average mean time to remediation of 233 days. In effect, that gives cybercriminals the better part of a year to exploit a known vulnerability. Of course, that’s usually longer simply because most IT organizations are not especially efficient when it comes to regularly updating all the components that make up an application once it’s been deployed in production.

Based on an analysis of more than 17,000 applications, the Sonatype report estimates downloads of Java components grew 68 percent (52 billion) year over year in 2016, while JavaScript downloads (59 billion) grew 262 percent.

Matt Howard, chief marketing officer for Sonatype, says managing all the components that make up an application will only become more challenging as developers increasingly start to leverage Docker containers. The Sonatype report estimates there will be 12 billion downloads of Docker containers in 2017, a 100 percent increase over 2016.

The good news is that more awareness of DevSecOps issues appears to be having an impact. The report finds the percent of Java components downloaded from the Sonatype Central Repository that contained known security vulnerabilities fell to 5.5 percent (1 in 18), down from 6.1 percent the year prior. Of course, that improvement needs to weigh against the 68 percent increase in downloads, which would suggest that the total number of components with known vulnerabilities finding their way into production applications has never been higher.

By way of contrast, the report claims that applications built by teams employing automated governance tools reduced the percentage of defective components in their application by 63 percent. The report also says organizations that are actively managing the quality of open-source components flowing into production applications are realizing a 28 percent improvement in developer productivity, a 30 percent reduction in overall development costs and a 48 percent increase in application quality.

The report makes clear that DevOps processes are not being extended far enough to the proverbial left. Instead of focusing on only on the application release cycle organizations need to apply structured processes to the components that are being aggregated together during the application development process. In fact, Howard notes that application development is moving away from being an art to more of a manufacturing process. As that shift continues to occur, it’s only a matter of time before a much greater emphasis gets placed on quality control all the way down that manufacturing line to not only limit liability but also generally improve the overall application experience.

— Mike Vizard

August 8, 2017