Bugcrowd | Claroty | GitHub | Synopsys
Q1. You were recently appointed as Bugcrowd's first chief operating officer. What's your immediate mission at the organization?
I am incredibly excited to join the team at Bugcrowd. For the past few years, I’ve had an opportunity to work with Bugcrowd in a number of different capacities as a customer, partner, advisor and, finally, as a part of the leadership team.
My mission coming into the business is to assist with developing operational rigor and processes to ensure that we continue to deliver value to our clients and partners as we scale in an efficient and profitable way. The business has seen a tremendous amount of growth over the past few years, and we're continuing to see increased demand across our Pentesting-as-a-Service, Bug Bounty, and VDP offerings. The growth isn’t slowing, and it’s critical we continue to put our business in a position to deliver for our clients.
Our mission has always been, and continues to be, to help our customers, their customers, and the broader industry defend against cyberattacks by leveraging the immense amount of talent in the researcher community. I could not be more proud to be a part of this team.
Q2. How would you say bug bounty programs have evolved in recent years? What are the biggest changes compared to a year ago and what do you perceive as the fundamental driver for growth in this space over the next few years?
For many years, organizations saw risk in “asking” researchers to find vulnerabilities in their environments, whether it be applications, networks, or infrastructure, and resisted leveraging them effectively. Today’s breach-regular environment has necessitated the need for organizations of all sizes, industries, and segments to embrace the collective intelligence, talent, and resourcefulness of the researcher community, or “crowd.”
Now, organizations readily accept that, whether they ask for it or not, cybercriminals are already attacking their environments. In turn, by tapping into the expertise of the global security community, we are able to help pair the right security expert, at the right time, with a customer’s environment by leveraging a unique and comprehensive AI-based platform.
Q3. What does Bugcrowd have planned for Black Hat Europe 2022? What can customers expect from your company at the event?
Black Hat provides Bugcrowd the opportunity to listen and share. What we are hearing as top-of-mind from our customers confirms there is so much ground to cover across the industry today. Customers have a lot to contend with in their security environments: limited resources and skill sets, integration hurdles, prioritization of vulnerabilities, compliance requirements, risk assessments, and more. Our primary focus is always to support and service our customers. As a partner and ally, we do that best by educating them on how to secure their environments and strengthen their security posture. Black Hat attendees can come by Booth 307 and consult our security experts. Further, we will share, results of recent industry reports; product demos showcasing our Crowd Match and Pen Test as a Service; new customer case studies; and explain how Bugcrowd’s Security Knowledge Platform provides a robust defense for today’s organizations.
Q1. How have threats targeting ICS and OT environments in general evolved in recent years? What do you perceive as the biggest threats to these environments over the next few years?
Highly interconnected cyber-physical systems, which include ICS/OT, medical devices, building management systems and more, have become pervasive across critical sectors due to the clear benefits they can deliver – driving innovation, resilience, sustainability, and better health outcomes, to name a few. However, this underlying connectivity can also heighten exposure to risks. As a result, in recent years we’ve seen an uptick in highly destructive cyberattacks that have taken advantage of security weaknesses in cyber-physical systems, such as:
The latest State of XIoT Security Report, released biannually by Claroty’s award-winning research arm Team82, reveals a number of key findings about the biggest threats to the Extended Internet of Things (XIoT), a holistic umbrella term that encompasses all cyber-physical devices connected to the internet. Key findings include:
Q2. What kind of capabilities will organizations require to secure the extended IoT (XIoT)? What are some of the questions security leaders need to be asking when procuring technologies for security the XIoT?
Enterprises are rapidly modernizing their industrial and commercial environments by deploying new XIoT assets alongside their existing brownfield equipment. These conditions are fueling new risk blindspots, amplifying scalability requirements across technology stacks, and leading to more types of cybersecurity stakeholders with increasingly complex needs. Claroty recently unveiled xDome to tackle these challenges and, ultimately, further enable enterprises to embrace digital transformation safely, securely, efficiently, and with confidence.
Based on extensive customer feedback and market research, Claroty has identified the following as key capabilities for securing the XIoT and specially designed xDome to deliver them:
When evaluating XIoT security technologies, security leaders should consider the following:
Q3. What is your main messaging at Black Hat Europe 2022? What do you expect customers will want to hear from Claroty at the event?
To put it simply, digital transformation has intensified so that an incredibly broad range of assets are now interconnected, making it difficult for a solution intended solely for ICS/OT, IoT, IoMT, or any other specific use case to cover all the bases. Understanding the need to secure enterprise XIoT environments holistically, Claroty provides unmatched visibility, protection, and threat detection for any and all connected assets in your environment, strengthening your overall cyber and operational resilience.
Q1. Public code repositories have become major attacker targets over the past year. Threat actors are exploiting the trust people have in these repositories to try and distribute malicious code and exploits. What needs to be done to address the issue?
Public code repositories, packages, and even private repositories have always been targets for threat actors, but that attack vector continues to grow as every company becomes a software company. While the software landscape is complex and changing rapidly, there are two areas where we, as developers and organizations, can all focus to make it harder for threat actors to be successful targeting this space.
Code security: Starting with the software development phase specifically, developers can implement commit signing and branch protection to ensure code changes are originating from trusted sources and reviewed before merging.
One common vector of attack comes from secrets being checked into code versus stored in a more appropriate location. Threat actors find these secrets either in public code, leaked code, or after an accidental exposure—for example misconfigured privacy settings—and then use the secrets to cause further compromise. Secret scanning tools that detect and alert on secrets in code or prevent them on push are key to preventing this type of attack.
Another growing threat comes from software dependencies. Most software is composed of many OSS dependency packages and it can be challenging for developers to have confidence in the security posture of each of those packages. Automated dependency management is critical to detecting and mitigating risks in this part of the supply chain. Software can have hundreds of dependent packages as part of the build, so it’s important to leverage tools that enable automated notifications and/or updates when dependencies become out of date.
GitHub is working hard to enable developers to detect and remediate dependency and code vulnerabilities during development and prevent secrets from being stored insecurely with GitHub Advanced Security (GHAS). Our Dependabot feature within GHAS enables automatic notifications and pull requests for outdated package dependencies. Our goal is to enable developers to have the software security tools they need integrated automatically into their daily flow.
Account security: Developer accounts are another frequent target for social engineering and account takeover and protecting developers from these types of attacks is the first and most critical step toward securing the supply chain. The best defense against this is moving beyond basic password-based authentication and adding 2FA as a powerful next line of defense.
At GitHub, we recently announced our 2FA requirement for all contributors of code on GitHub.com by the end of 2023. Enterprises should also consider phishing-resistant 2FA approaches (ex: FIDO2), SSO, and other account/identity strategies that enable proactive protection against account take over. We also continue to introduce improvements to npm account security. We believe that our unique position as the home for all developers means that we have both an opportunity and a responsibility to raise the bar for security across the software development ecosystem.
Q2. How does Sigstore help move the needle forward with software supply chain security? What can users do with Sigstore and GitHub Actions currently?
Sometimes it can feel like there’s a push-and-pull between security capabilities and usability. To move the needle forward with software supply chain security, we need to verifiably link built software back to its source code and build instructions. Sigstore starts with a usability improvement: when you build in a cloud CI/CD system like GitHub Actions, Sigstore lets you sign your build without having to maintain a private key. This “keyless signing” uses an OIDC token from the cloud CI/CD system to authenticate to Sigstore’s servers and receive a signing certificate. But that OIDC token has other metadata, like links to the source code and build instructions, that can also be included in the signing certificate. So what started out as a usability improvement—signing your builds without maintaining a private key—is now also a new security capability – being able to link a build back to its source code and build instructions.
Anyone can use Sigstore with GitHub Actions to do keyless signing leveraging “cosign sign” for container images or “cosign sign-blob” for any other build. This is great, but what do you do with that signature? You’re still responsible for storing, distributing, and verifying it before you deploy. That’s why we’re actively working within npm to enable the registry and CLI to understand, store, and help you verify these signatures. It’s exciting, but it’s just the first step, and we look forward to sharing a reference architecture with other package managers to make this capability available in more ecosystems.
Q3. What does GitHub have lined up for Black Hat Europe 2022? What do you want customers to take away from GitHub's participation in the event?
Software supply chain security continues to be pushed to the forefront this year, thanks in part to the continued increase in headline-driving attacks and further awareness driven by public sector priorities. As the home of open source and 90M developers, no team or platform is in a better position than GitHub to help advance the state of software security.
We see security as a team sport and understand that securing open source software will require community effort. We’re looking forward to spending time with the security community at Black Hat Europe, to share best practices and expertise, and coordinate our efforts against the most important critical issues.
We also have a number of sessions, with topics including preventing secret leaks in code, building securely on GitHub, and enabling collaboration between developers and security teams. I encourage attendees to stop by the GitHub booth (#107) to learn more about how GitHub enables developers and teams to build securely by default.
Q1. Synopsys Inc.'s latest edition of its Building Security in Maturity Model (BSIMM) report showed that many organizations have begun adopting a "shift everywhere" approach to software/application security. What exactly does shifting everywhere mean and what's driving the trend?
In traditional development models of the past, the best opportunity to reduce risk was to use dynamic application security testing (DAST) and pen testing just before production to find exploitable vulnerabilities in software. Testing at production is time-consuming and remediation can delay delivery. This is why we’ve seen organizations shift testing efforts earlier—left—in the software lifecycle. Doing static application security testing (SAST) on source code to remediate defects during development means that doing DAST and pen testing later in the cycle should uncover fewer problems, which means software can go to production in a timely manner. It’s also far cheaper to fix issues earlier in the process.
Now that organizations have seen “shift left” creates better software a little faster, they’re asking what other security activities can they move earlier in the development cycle? So, they’re adding threat modeling to the design phase, software composition analysis (SCA) to the build phase and fuzzing to the QA phase. Each of these security activities removes more defects. Software engineering has evolved into new tool chains, CI/CD, and DevOps. Building engineering workflows to automate software security “everywhere”—from the left and the right ends of the development lifecycle —means that there are more opportunities for integrating tools and for reducing the friction associated with those tools. In other words, we can now shift everywhere and carry out AppSec testing as early as possible for any kind of software artifact anywhere in the software lifecycle.
We see that evolution in the Building Security In Maturity Model (BSIMM) community of participating organizations. AppSec programs are spending more time putting testing and guardrails into their software lifecycles. They’re integrating testing results directly into developer workflows. They’re automating production sensors that tell when software is misbehaving. They’re creating bills of materials for software in developer workflows and using that as an input to risk management. The combined effort of the AppSec team and the engineering teams are really improving AppSec programs by embracing a shift everywhere mindset.
Q2. What kinds of tools and capabilities do organizations need to implement a truly scalable shift everywhere approach? Can organizations use their existing SAST and DAST tools or is there a need for other tools/capabilities as well?
“Shift everywhere” is less about tools than it is a mindset. It’s about development, security, and operations teams applying a variety of AppSec tools and techniques at multiple stages of the application lifecycle. The old model of confining AppSec testing to an activity done late in the development process by a dedicated team doesn’t work in a world where software release cycles are measured in weeks, days, or even hours. To address this, teams have “shifted left” by integrating and automating security testing into their development workflows. Doing this allows teams to find and fix security issues earlier, faster, and more cost-effectively.
But, performing security testing upstream during development doesn’t mean you don’t still need to run security tests downstream in production. A side-effect of the increasing complexity and velocity of software development is that teams may not have time to address every vulnerability they discover before they release their software to production. And other vulnerabilities may not be detectable until the software is deployed and running. So, teams also need to be “shifting right,” testing applications in production, both to validate upstream security tests but also to detect vulnerabilities in running applications before they can be exploited.
Can teams use their existing tools? Maybe, but they are likely to find that the tools that worked well for highly skilled security analysts aren’t well suited for use by developers on the left or operations teams on the right. You need to make sure development, security, and operations teams have the right AppSec tools for their needs, and aggregated visibility across all phases of the lifecycle. Doing this at scale means you need to choose tools for developers that they’ll adopt and use consistently; tools for DevOps which can be effectively integrated with existing toolchains and workflows; and tools for operations teams that can safely and continuously test production applications at scale.
Q3. What is Synopsys' focus at Black Hat Europe 2022 going to be? What do you have lined up for customers and security executives at the event?
Digital transformation continues to be a trend that organizations are undertaking to drive competitive advantage and often software is the enabler of this transformation. Software introduces new ways of doing business, but it also introduces risk. These risks include poor software hygiene, security, and reliability, and they arise because companies do not prioritize security when developing, procuring, and managing their business-critical software.
And the scary fact is that these software vulnerabilities can expose customer data and intellectual property and expose companies to financial and legal risk. Seemingly innocuous flaws can quickly escalate into existential threats to a business. Reputational, financial, and legal damage can result if risk isn’t controlled.
That’s why it’s important to establish trust in how your software was designed, built, and tested — whether it was developed in-house or procured from a third party — because once you deploy or use the software, you own the risk that comes with it.
Most software security companies are reactive — and only address risk after it’s too late. At Synopsys we turn that upside down by offering a holistic security approach that establishes trust early and maintains it so organizations can stop reacting and instead focus on driving their business forward. By creating a systematic way of developing software securely, it becomes a trusted asset rather than something that is suspect by default.
During Black Hat Europe, Synopsys expert, Steven Zimmerman, will present actionable guidance in his session entitled, “Building Security into DevOps Without Breaking It.” We hope that you will stop by booth #300 as well where you can learn more about Synopsys and how we can help you build trust in your software.
