After five months in beta, the GitHub Code Scanning security feature has been made generally available to all users: for free for public repositories, as a paid option for private ones.
“So much of the world’s development happens on GitHub that security is not just an opportunity for us, but our responsibility. To secure software at scale, we need to make a base-level impact that can drive the most change; and that starts with the code,” Grey Baker, GitHub’s Senior Director of Product Management, told Help Net Security.
“Everything we’ve built previously was about responding to security incidents (dependency scanning, secret scanning, Dependabot) — reacting in real time, quickly. Our future state is about fundamentally preventing vulnerabilities from ever happening, by moving security core into the developer workflow.”
GitHub Code Scanning
The Code Scanning feature is powered by CodeQL, a powerful static analysis engine built by Semmle, which was acquired by GitHub in September 2019.
“We want developers to be able to use their tools of choice, for any of their projects on GitHub, all within the native GitHub experience they love. We’ve partnered with more than a dozen open source and commercial security vendors to date and we’ll continue to integrate code scanning with other third-party vendors through GitHub Actions and Apps,” Baker noted.
“The major value add here is that developers can work, and stay within, the code development ecosystem in which they’re most accustomed to while using their preferred scanning tools,” explained James Brotsos, Senior Solutions Engineer at Checkmarx.
“GitHub is an immensely popular resource for developers, so having something that ensures the security of code without hindering agility is critical. Our ability to automate SAST and SCA scans directly within GitHub repos simplifies workflows and removes tedious steps for the development cycle that can traditionally stand in the way of achieving DevSecOps.”
Checkmarx’s SCA (software composition analysis) help developers discover and remedy vulnerabilities within open source components that are being included into the application and prioritizing them accordingly based on severity. Checkmarx SAST (static application security testing) scans proprietary code bases – even uncompiled – to detect new and existing vulnerabilities.
“This is all done in an automated fashion, so as soon as a pull request takes place, a scan is triggered, and results are embedded directly into GitHub. Together, these integrations paint a holistic picture of the entire application’s security posture to ensure all potential gaps are accounted for,” Brotsos added.
Leon Juranic, CTO at DefenseCode, said that they are very excited by this initiative, as it provides access to security analysis to over 50+ million Github users.
“Having the security analysis results displayed as code scanning alerts in GitHub provides an convenient way to triage and prioritize fixes, a process that could be cumbersome usually requiring scrolling through many pages of exported reports, going back and forth between your code and the reported results, or reviewing them in dashboards provided by the security tool. The ease of use now means you can initiate scans, view, fix, and close alerts for potential vulnerabilities in your project’s code in an environment that is already familiar and where most of your other workflows are done,” he noted.
A week ago, GitHub also announced additional support for container scanning and standards and configuration scanning for infrastructure as code, with integration by 42Crunch, Accurics, Bridgecrew, Snyk, Aqua Security, and Anchore.
The benefits and future plans
“We expect code scanning to prevent thousands of vulnerabilities from ever existing, by catching them at code review time. We envisage a world with fewer software vulnerabilities because security review is an automated part of the developer workflow,” Baker explained.
“During the code scanning beta, developers fixed 72% of the security errors found by CodeQL and reported in the code scanning pull request experience. Achieving such a high fix rate is the result of years of research, as well as an integration that makes it easy to understand each result.”
Over 12,000 repositories tried code scanning during the beta, and another 7,000 have enabled it since it became generally available, he says, and the reception has been really positive, with many highlighting valuable security finds.
“We’ll continue to iterate and focus on feedback from the community, including around access control and permissions, which are of high priority to our users,” he concluded.
Researchers discovered a malicious functionality within the iOS MintegralAdSDK (aka SourMint), distributed by Chinese company Mintegral.
Functional flow of a user ad-click being hijacked by the Mintegral SDK
Major privacy concerns
According to Snyk, SourMint actively performed ad fraud on hundreds of iOS apps and brought with it major privacy concerns to hundreds of millions of consumers.
On the surface, the MintegralAdSDK posed as a legitimate advertising SDK for iOS app developers, but its malicious code appeared to commit ad attribution fraud by secretly accessing link clicking activity within thousands of iOS apps that use the SDK.
SourMint also spied on user link click activity, improperly tracking requests performed by the app and reporting it back to Mintegral’s servers. Snyk’s researchers exposed SourMint and responsibly disclosed the information to Apple, alerting them to the active supply chain attack.
The SDK was distributed through Mintegral’s GitHub Repository, Cocoapods Package Manager for iOS; and Gradle/Maven for Android (which does not appear to be malicious). Unbeknownst to developers integrating it into their applications, the iOS versions of the SDK were malicious.
The SDK remained undetected for more than a year within the Apple App Store; SourMint first appeared in the 5.51 version of iOS in July 2019 continuing through version 126.96.36.199. Since then it has been identified in 1,200 iOS apps, including approximately 70 of the top 500 free apps found on the App Store, some of which are in the top 100.
Malicious iOS SDK functionality
Researchers found that SourMint has two major malicious functionalities in the SDK:
- Compromising app user privacy SourMint monitored and tracked when users clicked on links, spying on individual link activity by hooking onto the communication functions the iOS app user deployed. The SDK inserted itself via method swizzling into several functions responsible for opening resources in response to the user clicking on a link once it was installed. This allowed Mintegral to track all URLs accessed by the user and report the data back to Mintegral’s servers. This has impacted millions of consumers to date.
- Advertising attribution fraud SourMint was hijacking competing ad networks and consumers by manipulating click notifications used in attribution for app installs that were not actually generated by the Mintegral advertising platform. This process tricked attribution platforms to associate an install created by another source to Mintegral – manipulating the ‘last click attribution model’ commonly applied by attribution providers. This likely impacted the business of other advertisers and developers by taking away value that should have been attributed to them.
“As the first malicious SDK of this kind to infiltrate the iOS ecosystem, SourMint was very sophisticated. It avoided detection for so long by utilizing various obfuscations and anti-debugging tricks,” said Danny Grander, CSO, Snyk. “Developers were unaware of the malicious package upon deploying the application, allowing it to proliferate for more than a year. As cyber risk continues to ramp up, it’s critical for all software developers to mitigate the potential of malicious code making it into production and creating consumer privacy risk at this scale.”
New vulnerabilities in open source packages were down 20% compared to last year suggesting security of open source packages and containers are heading in a positive direction, according to Snyk.
Well known vulnerabilities, such as cross-site scripting, continue to be reported but aren’t impacting as many projects as they have in previous years. This is further encouraged as organizations start to drive a culture shift that embodies open source and container security as a core responsibility shared and integrated across development, security and operations teams.
This year the report took an even deeper look at vulnerability and ecosystem-level trends that impact the overall security posture of organizations relying on open source libraries.
Across the six popular ecosystems the report examined, there were fewer new vulnerabilities reported in 2019 than in 2018 – a promising finding – but there are still significant improvements to strive for with slightly less than two thirds of vulnerabilities still taking more than 20 days to remediate.
Common threats getting caught and remediated early
While well-known vulnerabilities in open source packages, such as cross site scripting are reported in high numbers, and the number of projects they impact are fairly low. These common threats appear to be getting caught and remediated early unlike some lesser known vulnerabilities.
For example, the report found certain vulnerabilities were reported in highly popular packages, affecting thousands of projects and thereby increasing the probability of them being exploited by attackers. Based on the report, the top vulnerability currently impacting scanned projects is prototype pollution in nearly 27% of all projects.
For the first time in the last four years, there has been a big shift in security mindset as organizations start embracing the core elements of DevSecOps and begin implementing more scalable programs and best practices to ensure shared responsibility.
Who should be responsible for designing and implementing security controls?
When respondents were asked the multi-answer question about who they felt should be responsible for designing and implementing security controls in their software development, development teams were commonly identified in addition to operations and security teams. This is a much more even spread across the three different teams compared to last year in which less than 25% felt security and operations played a role.
However, the fact the responses were all less than 65% still indicates that respondents did not typically identify all three groups as jointly being responsible. While progress has been made, it’s clear there is still a need for a more significant shift towards a shared-responsibility culture.
“This year’s report is very encouraging as we are seeing the volume of open source vulnerabilities trending down for the first time in four years. In addition, there are positive trends emerging around the collaboration of development, security and operations teams to address the growing demand for secure application development,” said Alyssa Miller, Application Security Advocate, Snyk.
“Despite the year over year progress, we must continue to prioritize security and empower organizations to implement programs to help drive DevSecOps and developers to be involved in securing their code from the very beginning. We need to focus on continuing these efforts to ensure these emerging trends continue on this positive trajectory in 2021 and beyond.”
Open source statistics
Open source ecosystems continue to expand, led by npm which grew over 117% in 2019 and spanning over 1,300,000 packages to this date.
- New vulnerabilities were down almost 20% across the most popular ecosystems in 2019.
- Cross-site scripting vulnerabilities were the most commonly reported.
- Two prevalent prototype pollution vulnerabilities resulted in an impact on over 25% of scanned projects.
- New vulnerabilities reported in common Linux distributions demonstrate the need for comprehensive monitoring for new vulnerabilities in container images.
- SQL Injection vulnerabilities, while decreasing in prevalence in most ecosystems, have increased over the last three years in PHP packages.
Container and orchestration challenges
- Official base images tagged as latest include known vulnerabilities; in particular the official node image which has almost 700 known vulnerabilities.
- Over 30% of survey participants do not review Kubernetes manifests for insecure configurations.
- Requirements for security-related resource controls in Kubernetes are not widely implemented.
- Increasingly, survey respondents feel that security for software and infrastructure should be shared among development, security, and operations roles.
- However, few organizations have programs in place to develop shared responsibility across the dev, sec, and ops personnel.