Use Code Security Audit for DevOps

DevOps teams may care about security, but it is not their area of expertise and it is not a priority for their pipeline goals. Adding security into the DevOps process adds friction and is difficult to get right, often taking years of trial and error for the early movers. GitLab’s Global DevSecOps Survey found that while over half of security teams are shifting left, 43% of security pros feel “somewhat” or “very” unprepared for the future. 

Consider this common scenario: an application development team is under pressure to release a new version of a mobile consumer banking app to address poor user experience and customer churn. Security is important to the organization, so they run static code application security testing (SAST) scans, fix the issues they deem to be critical, perform internal peer code reviews, run through QA testing, stage the app, and finally release it into production. The mobile app is live, but how secure is it?

The IT Security team, which is not embedded in the software development lifecycle (SDLC), needs to be sure that the mobile app is not susceptible to account takeover, remote code injection, cross-site scripting, and more. The security team then runs a pentest to ensure compliance and security coverage, and includes the mobile app in its continuous bug bounty program to discover more elusive vulnerabilities. Meanwhile, the CISO who’s responsible for keeping mobile banking customers safe from cybercriminals is concerned about the high likelihood of critical vulnerabilities in the source code of the mobile app.

HackerOne Code Security Audit provide a means for the CISO in this scenario to address the concern about critical vulnerabilities by leveraging a community of vetted, expert code reviewers to report findings as soon as they are found in the HackerOne platform alongside results from associated pentest engagements. HackerOne’s Pentest as a Service (PTaaS) engagements support many assessment types, including web, mobile, AWS cloud, APIs, and external networks. The addition of Code Security Audit adds depth to security coverage by giving them the means to audit the security posture of DevOps practices. 

Identify Risks in Code with Expert Reviewers

Experienced, expert human code reviewers uncover critical vulnerabilities that SAST scans miss, avoid false positives, and understand the context in order to provide specific, situational guidance for remediation. 

An average of 37 medium to critical vulnerabilities are discovered in initial repository reviews by HackerOne’s code reviewers.

Some key capabilities include:

• Breadth of Security - All common programming languages, frameworks, and platforms are supported.
• Depth of Security - Reviewers apply a comprehensive approach, aided by a combination of HackerOne's homegrown automation engine and internal technical experts, which work to capture key data to fast-track  the review process and maximize reviewer time spent on the most important and high-risk areas of the code base.
• Operational Efficiency - Reviewers can integrate into your team's existing code review processes and pipelines. Software integrations with CI/CD tools lead to faster and more effective remediation.
• Verified Reviewers - Our exclusive community of over 600 background-checked , vetted engineers typically have 5+ years of application security and engineering management experience. We adhere to strict NDA and PIIA protections.

Secure Integrations and Controls

The Code Security Audit solution supports all major source control providers, both cloud and self-hosted, with integrations to GitHub, GitLab, Azure DevOps, Bitbucket, and others. The solution is managed with the same controls as any other CI/CD tools in use.  

Since source code review is a form of white box testing, we take access control and identity governance very seriously. As such, we provide granular access control, enforce least privilege access to code, provide full audit logs, and include single sign-on for developers and security teams.

A Key Addition to the HackerOne Attack Resistance Platform 

HackerOne Pentest, along with the new Code Security Audit, is an integral capability of our Attack Resistance Platform. By unlocking the value of our community of security researchers to do reconnaissance and risk ranking on assets, along with both continuous and formalized security testing, you can help make meaningful gains in closing the security gaps in your attack surface. 

To learn more about HackerOne Code Security Audit reach out to us directly for more information.

This week HackerOne hosted a series of webinars that asked participants about how they rated their level of vulnerability management maturity. We asked how regularly they tested their digital assets, which assets they tested and how they prioritized them, and whether they had a way for friendly hackers to tell them about any vulnerabilities. At least 90% had some sort of prioritization process in place to deal with vulnerabilities, only 28% conducted continuous security testing, but 59% admitted to having no way for third party researchers to submit bugs. 

Of course, a company’s level of vulnerability management maturity usually aligns with how sophisticated and extensive their technology use is. A mature vulnerability manager will know what assets they have, assess them regularly, remediate any vulnerabilities and feed that information back into the SDLC - and recognize that it can’t be done without the help of third party researchers to close the gaps. 

During the webinars, we caught up with Matt Southworth, CISO of Priceline, and Matt Adams, Global Security Architect at Costa Coffee, to learn their 5 secrets to building a highly effective vulnerability management program. One that embraces uses a variety of tools, that communicates effectively, that covers all bases, can adapt to changing needs and, above all, can demonstrate success.

1. USE ALL THE TOOLS

Matt A: “At Costa we use automated scanners find the ‘low hanging fruit’ and highlight those areas we need to spend more time on, along with static and dynamic testing during the product release timeline to detect common vulnerabilities, such as those found in the OWASP Top 10. After that, we hand things off to the bug bounty program to find the things we couldn’t find ourselves. We expect really high value results from bug bounty as these vulnerabilities will be things the automated scanners haven’t picked up, and typically take human creativity and/or ingenuity to exploit. For example, we had a report where a hacker found a registration endpoint for a portal, which, although it had been superficially removed, would have allowed them to create an administrator account on a customer facing website by manually building an API request to trigger the account creation process.”

2. OVER-COMMUNICATION DOESN’T HURT 

Matt S: “The mistake we see most often is when there’s confusion over who owns the app that a vulnerability has been found in and it gets sent to the wrong team, slowing the whole process down. Having clear dashboards that show where you’re at, what the problems are and, most importantly, where those problems map back to and who the owner is, will help speed that remediation process up. The difference between vulnerability assessment and vulnerability management is that assessment is a process with input and output, whereas management is about being able to communicate clearly to your organization about risk tolerance. Once you can make your stakeholders care about the risk you should then over-communicate to demonstrate where you’re at and what the pain points are.”

3. IDENTIFY YOUR BLIND SPOTS

Matt S:” Every organization has blind spots. Having the hacker community on the other side of the screen looking at those things you’ve missed means you can close those holes. Blind spots could be anything from an employee purchasing software you’re not aware of to low level vulnerabilities that when chained together could have a significant impact. The most common blind spot we find is regressions; when you think you’ve identified and solved an issue but it’s still there or returns after the fix. That’s where retesting comes in to provide an extra layer of security.”

4. EMBRACE FLEXIBILITY 

Matt A: “We have different patching schedules for different devices and services in our estate, largely dictated by each vendor’s release schedule. We adhere to those patching cycles as much as possible, but, when products have more sensitive and complex releases, we will add in additional testing cycles. If we’ve seen a vulnerability exploited in the wild, or had a warning from an industry body about a vulnerability, then it’s important that we have the flexibility to be able to patch ahead of the planned schedule. You need to find the balance between maintaining the usual patch process and the disruption of ad-hoc patches.”

5. MEASUREMENT EMPOWERS MITIGATION 

Matt S: “Categorising success can be as simple as measuring the time to detect vulnerabilities, the time to fix and how the team is hitting the SLAs to fix them. Having visibility of which vulnerabilities are popping up over and over means you can focus on where the problems are, and work towards educating those system owners on how to avoid them.”

To listen to the webinars in full, you can find them on demand here: https://www.hackerone.com/resources/on-demand-videos