Copilot Autofix in GitHub Advanced Security (GHAS) analyzes vulnerabilities, explains their importance, and offers suggestions on how to remediate them. 

“For developers who aren’t necessarily security experts, Copilot Autofix is like having the expertise of your security team at your fingertips while you review code,” Mike Hanley, chief security officer and SVP of engineering at GitHub, wrote in a blog post.  

When GHAS finds a vulnerability, there is now a button that developers can click and have Copilot Autofix generate a fix. Then, developers can either dismiss the suggestion or have it create a new pull request with a code change that remediates the issue. 

It can generate fixes for dozens of classes of vulnerabilities, including SQL injection and cross-site scripting. 

Copilot Autofix was first introduced as a public beta in March, and according to the company, beta participants were able to fix vulnerabilities three times faster than developers fixing them manually. Fixing cross-site scripting vulnerabilities was seven times faster and fixing SQL injection vulnerabilities was 12 times faster. 

According to GitHub, Copilot Autofix will help cut down on technical debt when it comes to vulnerabilities. The company explained that the longer a vulnerability remains in a codebase, the more difficult it is to remove them.

“When a developer is asked to fix vulnerabilities in code that they haven’t seen in a while or aren’t familiar with, it can take hours to assess the surrounding code and experiment with manual fixes,” Hanley wrote.

The new functionality is available to any GitHub customer with an Advanced Security license, and, starting in September, Copilot Autofix will be made available for free to open source maintainers as well. 

“As the global home of the open source community, GitHub is uniquely positioned to help maintainers detect and remediate vulnerabilities so that open source software is safer and more reliable for everyone,” Hanley wrote. 

You may also like…

Harness software intelligence to conquer complexity and drive innovation

Software engineering leaders must act to manage integration technical debt

The post GitHub’s Copilot Autofix generates remediation fixes for code vulnerabilities appeared first on SD Times.

This is compared to around 75% for JavaScript services, 64% for Python, and 50% for .NET. The average for all languages studied was 47%

The company found that Java services are also more likely to be actively exploited compared to other languages. Fifty-five percent have suffered from this, compared to a 7% average for other languages.

Datadog believes this may be due to the fact that there are many prevalent vulnerabilities in popular Java libraries, such as Tomcat, Spring Framework, Apache Struts, Log4j, and ActiveMQ. 

“The hypothesis is reinforced when we examine where these vulnerabilities typically originate. In Java, 63 percent of high and critical vulnerabilities derive from indirect dependencies— i.e., third-party libraries that have been indirectly packaged with the application. These vulnerabilities are typically more challenging to identify, as the additional libraries in which they appear are often introduced into an application unknowingly,” Datadog wrote in the report.

The company says this serves as a reminder that developers need to consider the full dependency tree when scanning for application vulnerabilities, not just the direct dependencies.

The second major finding of the report is that the largest number of exploitation attempts is done by automated security scanners, but that most of those attacks aren’t harmful and are just a source of noise for companies trying to defend against attacks.

Only 0.0065 percent of attacks performed by automated security scanners actually triggered vulnerabilities. 

Given the prevalence of these attacks but their harmlessness, Datadog believes this underscores the need for a good system for prioritizing alerts. 

According to the report, over 4,000 high and 1,000 critical vulnerabilities were discovered by the CVE project last year. However, research published in the Journal of Cybersecurity in 2020 found that only 5 percent of vulnerabilities are ever actually exploited. 

“Given these numbers, it’s easy to see why practitioners are overwhelmed with the amount of vulnerabilities they face, and why they need prioritization frameworks to help them focus on what matters,” Datadog wrote. 

Datadog found that organizations who have made efforts to address their critical vulnerabilities have success in removing them. Sixty-three percent of organizations that had a critical CVE at one point no longer have any, and 30% have seen the number of critical vulnerabilities reduced by half.  

The company recommends that organizations prioritize vulnerabilities based on if the impacted service is publicly exposed, the vulnerability is running in production, or there is publicly available code for the exploit. 

“While other vulnerabilities might still carry risk, they should likely be addressed only after issues that meet these three criteria,” Datadog wrote. 

Other interesting findings in Datadog’s report are that lightweight container images lead to fewer vulnerabilities, adoption of infrastructure as code is high, manual cloud deployments are still widespread, and usage of short-lived credentials in CI/CD pipelines is still low.

The post Report: Java is the language that’s most prone to third-party vulnerabilities appeared first on SD Times.

However, thousands of code vulnerabilities are discovered, patched, and publicly disclosed every year to improve security for current and potential users. Finding code vulnerabilities is not only an intellectual challenge for ethical researchers but also allows them to examine real-world cases, test and refine rules, and enhance products. In addition, vulnerability reports assist in keeping users and affected businesses safe. 

Therefore, it is important to have resources dedicated to this effort. This article will discuss top vulnerabilities discovered in widely-used applications, the commonalities amongst these vulnerabilities, and how clean code practices from the ground up can prevent vulnerabilities from entering their apps and services in the first place. 

Discoveries in Popular Applications

WordPress is utilized by almost 40% of all websites and is the most widely used content management system in the world. Thanks to its simplicity, millions of users can host their blog, eCommerce site, or static website. In the past, a number of security hardening measures have been added to WordPress’s code base to safeguard its users. However, an Object Injection vulnerability was recently found, which is a code vulnerability that allows attackers to insert PHP objects of any type into the application to then use it to alter the application’s logic at runtime. This could also allow an attacker to perform different kinds of malicious attacks or even lead to a full site takeover. 

Another vulnerability discovered was in Zimbra Email, a popular webmail solution similar to Microsoft Exchange. According to its website Zimbra is used by over 200,000 enterprises, universities, and financial and government institutions around the globe. With the solution’s mail servers, load balancing features, and a powerful web interface, users can log in to their Zimbra mail accounts to read and send private emails. Ethical researchers discovered a Memcache Injection in Zimbra which lets an attacker target and steal login information from users of a targeted Zimbra deployment. With mail access, attackers may be able to get access to various internal systems and take extremely sensitive data. They can also change passwords, pose as their victim, and listen in on every private conversation within the targeted business.  

Commonalities in Code Vulnerabilities

Security vulnerabilities are ubiquitous. Even complex, hardened code-bases can contain potentially serious flaws. However, there is one commonality in many exploited vulnerabilities – most security vulnerabilities are in the source code of business applications, and many of these security issues can be discovered early during development. 

Developers today are doing a great job of delivering new and enhanced features to meet the demanding time-to-market requirements. In this role, they ensure that the code they develop is functional, performant, and error-free. Today, most organizations require code security checks to be closely governed by security champions where these checks are usually performed in later stages of the development workflow. The effect of this delay means that issues discovered later (or missed completely) add long feedback loops to the developer. This requires developers to switch their current context to focus on fixing issues long after they’ve committed their original code. As a result, product time-to-market and developer productivity take a direct hit. 

The “Clean as You Code” Approach to Writing Secure Code 

The “clean as you code” approach addresses security at the core, when code is being written, and provides developers with the tooling and education they require to deliver quality, secure code. Code that is not adequately maintained, reliable, or of lower quality is susceptible to security issues. There is no one better positioned to fix issues in code than the developer actively working on it.

When security considerations are part of the development workflow and are addressed up front, the overall burden on security and development teams reduces significantly, as fewer issues reach final security checks. This means no more after-the-fact costly rework and lengthy feedback cycles. The result is a streamlined and efficient approach to handling code security.

To conclude, vulnerabilities in source code can be detrimental to an organization’s reputation. Adopting simple, non-disruptive clean code best practices can help organizations mitigate threats, combat the problem of vulnerabilities recurring in code, and extend the lifetime of their business application as a result.

Johannes Dahse is head of R&D at SonarSource

The post How clean code can help prevent headline-grabbing vulnerabilities appeared first on SD Times.

The new capability leverages Veracode’s Dynamic Analysis (DAST) scanning engine to provide comprehensive security insights and remediation guidance for APIs.

“The explosion of APIs means that application development is becoming more fragmented and decentralized in nature, so the attack surface is growing exponentially,” said Brian Roche, chief product officer at Veracode. “As such, API scanning has become the most-requested feature by our customers as they look for a solution that saves time, frees up resources, and provides peace of mind.”

API scan results are grouped by severity and provide detailed remediation guidance within a single dashboard alongside other Dynamic Analysis scans. This makes it easy for security teams to prioritize vulnerabilities and access the details required for developers to fix insecure code quickly, facilitating smooth collaboration between security and development teams, according to the company on its website.  

“Strong API security is fast becoming one of the top concerns for enterprises and a table stakes capability for CISOs. In a world where every relationship should start with zero trust, regular API scanning must be a cornerstone of any robust software security strategy,” Roche added. 

The post Veracode launches scanning tool to find API vulnerabilities appeared first on SD Times.

Traditionally, software supply chain exploits, such as the Struts incident at Equifax, depended on an organization’s failure to patch a known vulnerability. More recently, supply chain attacks have taken a more sinister turn because bad actors are no longer waiting for public vulnerability disclosures. Instead, they’re injecting malicious code into open-source projects, or building malicious components that feed the global supply chain.

No one in the enterprise, including developers, knows all of the components that an application comprises, nor do they understand all the dependencies associated with those components. It’s a potential liability issue that, combined with a demand for greater transparency, has fueled the adoption of software composition analysis (SCA) and software bill-of-materials (SBOM) tools.

“We’ve created package managers that make it easy and fast for developers to reuse binary components which arguably makes them more productive, but those tools also introduce transitive dependencies,” said Brian Fox, CTO of Sonatype. “If I pull one thing, that thing pulls in its dependencies and in Java it’s not uncommon to see a 10x or even 100x explosion. In JavaScript it’s even worse, 100x to 1,000x.”

Next-Generation Supply Chain Attacks Are Growing

According to Sonatype’s 2020 State of the Software Supply Chain report, the number of next-generation cyberattacks actively targeting open-source projects increased 430% year over year. From February 2015 to June 2019, 216 such attacks were recorded. Then, from July 2019 to May 2020, an additional 929 attacks occurred. These next generation supply chain attacks are increasing for three reasons. 

First, open-source projects rely on contributions from thousands of volunteer developers and it’s difficult or impossible to discern between members with good or malicious intent.

Second, when malicious code is secretly injected “upstream” to the developer via open source, it’s highly likely that no one realizes the malware exists, except for the person who planted it. This approach allows adversaries to surreptitiously set traps upstream and carry out attacks downstream once the vulnerability has moved through the supply chain into the wild.

Finally, open-source projects typically incorporate hundreds or thousands of dependencies from other open-source projects, many of which contain known vulnerabilities. While some open-source projects demonstrate exemplary hygiene as measured by mean time to remediate (MTTR) and mean time to update (MTTU), many others do not. The sheer volume of open source and the massive number of dependencies makes it difficult to quickly evaluate the quality and security of every new version of a dependency.

Why Approved Component Lists Don’t Help

The dynamic nature of software development is at odds with approved component lists because the lists are not to be updated as often as they should be. The task is too complex and time-consuming for humans.

“There are millions of components if you include the multiple ecosystems that are out there, and they’re changing four, 10, 100 times a year. How can you be sure that what was okay a year ago is still okay?” said Fox. “People are still using Struts because it’s on their approved list even though it’s been a level 10 vulnerability for about 15 years now.”

Modern enterprises need the ability to define policies that can be applied to individual components whether the rule is based on licensing, the age of the component, the popularity of the component or other criteria. Once the policy has been defined, it can be executed automatically.

“With tooling, you can inspect the software, run those policies, understand why a certain component wasn’t used in this application and recommend a better one. By codifying all that, you can avoid walking over to legal, architecture or security to ask permission,” said Fox. 

While static and dynamic analysis tools help identify problems in code, their capabilities may not extend to third-party code because there are too many code paths to evaluate. So, the vast majority of code may not be scanned, giving developers a false sense of security.

In addition, when a developer downloads and runs a malicious component, that component could install a backdoor on their system. Similarly, with continuous integrations, the poisonous code can seep even further into the pipeline.

“Attackers are now focused on the developers and the development infrastructure as the way into the organization,” said Fox. “That way, they can bypass all the enterprise security stuff like firewalls. By abstracting the sheer complexity of application components and their dependencies into policies, you can provide developers with guardrails that help improve application security and those developers don’t have to others in the organization for permission every time.”

Learn more at www.sonatype.com.

Content provided by Sonatype

The post How hackers poison your code appeared first on SD Times.

“The APVI is designed to drive remediation and provide transparency to users about issues we have discovered at Google that affect device models shipped by Android partners,” the Android team wrote in a blog post.

The APVI covers Google-discovered issues that could potentially affect the security posture of an Android device or its user and is aligned to ISO/IEC 29147:2018 Information technology — Security techniques — Vulnerability disclosure recommendations, according to the company. 

It also covers a wide range of issues that are not serviced or maintained by Google and are handled by the Android Security bulletins. 

“The APVI has already processed a number of security issues, improving user protection against permissions bypasses, execution of code in the kernel, credential leaks and generation of unencrypted backups,” Google stated. 

This includes an issue in which some versions of a third-party pre-installed over-the-air (OTA) update solution, a custom system service in the Android framework exposed privileged APIs directly to the OTA app. Google worked with the impacted OEMs to make them aware of this security issue and provided guidance on how to remove or disable the affected code.

Another fixed issue included a credential leak, in which a  popular web browser pre-installed on many devices included a built-in password manager for sites visited by the user. It also helped discover a ‘checkUidPermission’ method in the ‘PackageManagerService’ class that was modified in the framework code for some devices to allow special permissions access to some apps.

Google also has a number of other security features to help keep the Android platform and ecosystem safe such as the ability to report vulnerabilities in Android code via the Android Security Rewards Program (ASR) or to report vulnerabilities in third-party Android apps through the Google Play Security Rewards Program. 

“Until recently, we didn’t have a clear way to process Google-discovered security issues outside of AOSP code that are unique to a much smaller set of specific Android OEMs,” the team wrote. “The APVI aims to close this gap, adding another layer of security for this targeted set of Android OEMs.”

The post Android Partner Vulnerability Initiative launched to help manage security issues appeared first on SD Times.

This is according to HackerOne‘s recently released report on the top 10 list of vulnerabilities based on the total amount of bounties paid per vulnerability type. The report analyzed HackerOne’s proprietary data examining more than 120,000 unique security weaknesses resolved on the HackerOne platform through the 2018 calendar year.

RELATED CONTENT: Why do the same vulnerabilities keep showing up?

“At its core, the vulnerabilities are ranked by the total amount of bounties paid per vulnerability type. These payments are evaluated by severity and dictated by the companies themselves, showcasing the importance they place on each type,” said Miju Han, director of product management at HackerOne.

Cross-site scripting maintains the top spot because it accounts for about 35 percent of all reported vulnerabilities by volume and for about 28 percent of all bounties paid. Information disclosure vulnerabilities known for revealing sensitive information are still common, presenting serious risk to organizations and accounting for large bounty sums, according to Han.

HackerOne noticed that there is a discrepancy between the seriousness of the XML external entities (XXE) vulnerability and the amount that companies are willing to dish out through the white hat hacking platform.

“XXE is an interesting vulnerability because it is often serious (67 percent of the time it is critical or high), but it’s only 2 percent of our bounty payouts, and it’s less than 1 percent of the vulnerabilities found on our platform,” Han said.

Meanwhile, the OWASP Top 10 list, which has seen many iterations since its inception in 2001 and has since become the go-to list for vulnerabilities, ranked XXE as the fourth-highest vulnerability.

HackerOne says that less than half of this edition overlaps with the OWASP Top 10. However, both Top 10 lists still rank injections, broken authentication and sensitive data exposure among the highest vulnerability risks.

OWASP founder Jeff Williams, who is also the co-founder and CTO of Contrast Security, explained bug bounties don’t paint the whole picture of the scope or scale of vulnerabilities.

“I sort of get that there’d be a correlation between what people are paying for and what the bug bounties are, but it’s really not typically like that. The incentives for bug researchers aren’t the same as the incentives for hackers,” Williams said. “Most companies put out a bug bounty that says any high or critical vulnerability will pay you a thousand dollars, but they’re not really parsing it down to all the details saying that SSRF is one point three times as important as XSS.”

Rather than describing the list as redundant, Williams said HackerOne should participate in the OWASP 10 and that a conglomerate of surveys that essentially takes all the sources, weighs and analyzes them would result in a really good picture of what’s going on. He says Top 10 lists don’t cover all of the vulnerabilities companies should be looking out for.

“If all you’re doing is securing against the Top 10, then you’re in a serious world of hurt right now,” Williams said.

Han from HackerOne agreed that reviewing multiple reports of the Top 10 risks would be beneficial for companies looking to bolster their security.

“The reality is that security organizations need multiple frameworks for prioritizing vulnerabilities. Both assets will be able to help security teams identify the top risks, ours just also takes into account volume and bounty values, which we think will be of particular interest to security teams looking to protect against criminal hackers.” said Miju Han.

HackerOne lists these as the highest security risks:

1. Cross-Site Scripting: A type of injection, in which malicious scripts are injected into otherwise benign and trusted websites.
2. Improper Authentication: Software does not prove or insufficiently proves that an identity claim is correct.
3. Information Disclosure: A weakness that leaks sensitive data.
4. Privilege Escalation: A bug that allows an adversary to obtain a higher level of permissions on a system or network.
5. SQL Injection: Insertion of a SQL query via the input data from the client to the application.
6. Code Injection: A general term for attack types that consist of injecting code that is then interpreted/executed by the application.
7. Server-Side Request Forgery (SSRF): Allows the attacker to abuse functionality on the server to read or update internal resources.
8. Insecure Direct Object Reference (IDOR): Enables attackers to bypass authorization and access resources in the system directly.
9. Improper Access Control: Software does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
10. Cross-Site Request Forgery (CSRF): Forces an end user to execute unwanted actions on a web application in which they’re currently authenticated.

The full report is available here.

The post HackerOne: The top 10 security vulnerabilities appeared first on SD Times.

“We are excited about what this acquisition means for our customers in terms of increased support for SCA in DevSecOps environments and the ability to confidently use open source components without introducing unnecessary risk,” Sam King, general manager of CA Veracode wrote in a blog post

According Sam King, open-source libraries are becoming extremely important because of its ability to save time, reduces inefficiency, and increase developer productivity, but these libraries come with risks. King revealed that 88 percent of Java applications recently analyzed by CA had at least one component-based vulnerability. “With the acquisition of SourceClear, we’re taking a great step forward in bringing that same combination of security, productivity and efficiency to the way developers use and test open source libraries, so that our customers can use open source libraries to accelerate software development without adding unmanaged risk,” King wrote in a blog post.

King says the SourceClear’s SCA solution can not only inform the user about vulnerable components, but also whether that component is being utilized in the application, reducing false positives related to unused components in an open-source library which may be insecure, but inconsequential to a project.

According to projections by SourceClear, there will be nearly a half-billion open-source libraries available to developers within a decade, and the company has aimed to future-proof their utility.

“In addition to tracking public sources like CVEs, SourceClear constantly data-mines millions of commits in open-source libraries, watches thousands of bug-trackers and parses the change-logs of popular libraries,” King wrote. “As a result, customers can even find vulnerabilities that have not been reported to NVD. Each issue includes prescriptive fix information, much of which can be automated to increase speed.”

The post CA Technologies acquires SourceClear for its DevSecOps portfolio appeared first on SD Times.

“Netflix’s goal is to deliver joy to our 117+ million members around the world, and it’s the security team’s job to keep our members, partners, and employees secure,” the company wrote on its blog.

As part of the program, the company requires researchers don’t access customer or employee information, stop testing and report issues immediately, don’t degrade the company’s user experience, perform research only, use the Bugcrowd submission form to report vulnerabilities, and collect only the information necessary to demonstrate vulnerabilities.

More information is available here.

InfluxData announces support for Apache Arrow with Go implementation
InfluxData announced it will be contributing its Go programming language implementation to the Apache Arrow project. According to the company, the move is to signify its support for the Apache Software Foundation. Apache Arrow is a cross-language development platform for in-memory data. The Go language implementation for Arrow will include CPU specific optimizations to increase performance and analytic workloads on Arrow.

“We are excited to have the support offered by InfluxData and appreciate the company donating its Go language expertise and implementation to Apache Arrow in the spirit of benefiting the greater Open Source community,” said Jacques Nadeau, VP for Apache Arrow. “Go is becoming an increasingly popular language, and having InfluxData contribute code to Apache Arrow will increase its adoption across the industry.”

Hortonworks announces Operational Services for managing big data
Hortonworks announced a new solution to improve data-driven insights. The Hortonworks Operational Services is designed to manage big data deployments and help customers maximize the value of their data. The services will benefit customers using the Hortonworks Data Platform and Hortonworks Dataflow solution. It features support for HDP and HDF environments, configuration, management and maintenance for HDP components, multi-tenancy management within the cluster, capacity planning and forecasting and quarterly on-site architecture review.

“At its heart, Hortonworks Operational Services is designed to reduce complexity when building, deploying and managing big data, whether it is on-prem or in the cloud,” said Scott Gnau, chief technology officer at Hortonworks. “Hortonworks has extensive experience running the entire Apache Hadoop stack in production, at scale, on the most demanding workloads. With a proven track record of supporting our big data platforms at leading companies and on multiple tiers, we are in a unique position to efficiently manage the operations of customer environments at high performance.”

GitHub aims to keep code safer with security alerts
GitHub announced security alerts last year as a way to provide private and public repositories with vital vulnerability information. Since then, the company has taken an active role in alertying projects of vulnerabilities in RubyGems for Ruby and npm for Javascript. Going forward, the company will look for new ways to improve code checking and generation.

“As more developers draw from existing code libraries to build new tools, tracking changes in dependencies like security vulnerabilities has become more difficult,” GitHub wrote in a post. “In almost all cases, there’s a new, patched version of the library we can recommend in the alert.”

The post SD Times news digest: Netflix bug bounty program, InfluxData’s Apache Arrow support, and GitHub’s security alerts appeared first on SD Times.

According to Synopsys, the acquisition of Black Duck will help provide its customers with visibility into open source software. Black Duck provides automated solutions that detect known security vulnerabilities and license compliance issues.

“Since the creation of the Synopsys Software Integrity Group, we have been striving to offer a comprehensive, end-to-end portfolio for software security and quality. The acquisition of Black Duck is an important step in this process, giving companies a scalable approach for minimizing software-related business risk, ensuring timely product releases at predictably lower cost, and ensuring internal and external standards compliance,” Andreas Kuehlmann, general manager of the software integrity group at Synopsys, wrote in a post.

As part of the acquisition, the Synopsys Software Integrity portfolio will feature static code analysis, fuzz testing tools, software composition analysis tools, interactive application security testing, and deep linking to training modules.

“The two companies are strategically aligned, with a shared vision of building security and quality into the software development life cycle and across the cyber supply chain. Black Duck will enhance our efforts in the software security market by broadening our product offering and strengthening the Software Integrity Platform,” Kuehlmann wrote.

The post Synopsys acquires Black Duck Software appeared first on SD Times.