Grip Security Builds Customer Trust with AppSec
Grip Security values strong application security because it helps them build trust with their customers. Learn how a security company approaches AppSec.
Grip Security values strong application security because it helps them build trust with their customers. Learn how a security company approaches AppSec.
Grip Security values strong application security because it helps them build trust with their customers. Learn how a security company approaches AppSec.
Grip Security values strong application security because it helps them build trust with their customers. Learn how a security company approaches AppSec.
Grip Security values strong application security because it helps them build trust with their customers. Learn how a security company approaches AppSec.
.png)
This blog is by Idan Fast, co-founder and CTO of Grip Security.
Grip Security is a security vendor that provides businesses with visibility and control over their SaaS ecosystems. This helps security teams understand how company data is being used across SaaS applications, identify potential risks, and enforce the right security policies.
As a security vendor, we must prioritize AppSec, and the nature of our business dictates two unique reasons it’s important to us:
- Brand: The level of trustworthiness we need to achieve for our brand is higher than non-security vendors because customers entrust Grip with access to their sensitive data and systems. A strong AppSec program demonstrates Grip's commitment to protecting this data and minimizing the risk of a breach.
- Customer expectations: As a vendor that helps security teams onboard applications securely, we'd like to go above and beyond when we are being assessed. Additionally, our points of contact, being part of the secure application onboarding process themselves, have a deeper understanding of potential risk that can be brought in by a new tool, and will evaluate it accordingly.
Both drivers come down to one simple sounding goal: Establish trust.
As a security vendor, the level of trustworthiness we need to achieve for our brand is higher. Customers entrust us with access to their sensitive data and systems. A strong AppSec program demonstrates our commitment to protecting this data.
Three ways to evaluate “trust” in a security vendor
Organizations typically focus on three categories when evaluating a security vendor — compliance posture, security questionnaires, and a trust center — so that’s where we spend the most time demonstrating trust.
Compliance posture
Requests for compliance and security assessments frequently happen at two stages during customer engagements, either during the procurement process or as a prerequisite to starting a proof of concept. If we can’t quickly and accurately respond, or even pre-empt these requests, we may introduce unneeded friction into our process.
To demonstrate our compliance posture, we use SaaS/cloud-related self-assessments (aligned to SIG, CAIQ, and CISA Cloud Controls Matrix) and externally audited frameworks (e.g. SOC 2, ISO 27001) that have direct provisions on AppSec programs. Self-assessments help us ensure we’re using secure SDLC practices, and having canned responses for these self-assessments helps us accelerate our assessment processes.
Security Questionnaires
We also actively engage with our customers through detailed security questionnaires, which can (but don’t always) map to a compliance standard. Larger enterprises are more likely to include custom questions and it’s also common for them to evaluate tools differently based on the sensitivity of the systems accessed.
These questionnaires request detailed information about cloud security and AppSec. For example, one questionnaire we recently received had questions on:
- Application and services security - Planning: Standards, training, code repos, and our development and production environments
- Application and services security - Development: Design, testing, and remediation
- Application and services security - Production: Preventative controls, monitoring, and response controls
- Software-as-a-Service (SaaS) Protection: Application protection
The three AppSec topics that feature most commonly in questionnaires are pentesting (manual and automatic), vulnerability management SLAs based on criticality, and tooling (SCA, SAST, etc). We rely on our tools to help us answer assessments, which means the tool has to provide the right information quickly and accurately. For example, a deep questionnaire could ask How quickly can we remediate vulnerabilities with a medium or higher severity? To answer this question, I pull two data points to provide strong evidence that we can comply with their expectations:
- No currently open, exploitable findings
- Our mean time to remediation for vulnerabilities
Trust center
Finally, our trust center is how we maintain transparency about our security practices and demonstrate that we’re on top of it. In addition to documents such as our privacy policy, the trust center also includes pre-filled compliance assessments that can greatly cut down the amount of time it takes to respond.
In enterprise accounts, there are differences between TPRM/GRC review and the architecture/product security reviews. It’s important to understand that satisfying TPRM/GRC requirements doesn’t necessarily give peace of mind to practitioners because compliance reviews focus on the vendor, rather than the implementation architecture. Security practitioners want additional information on how we manage two threats:
- How we manage data access: As a security vendor committed to least-privilege access, we have practices that minimize our data access beyond what’s provided by the permission models in the target systems we integrate into.
- Potential exposure in the event of a breach: We document how our tools/processes decrease the possibility of a breach, for example using an SCA tool to identify exploitable open source risks. We also cover cloud infrastructure elements, like tenant separation, and PAM/secrets management.
How we approach AppSec
Our engineers are very well educated on secure SDLC best practices because we optimize hiring for that profile. They know what CVEs are and the importance of remediation, which means we don’t have to explain why vulnerability management is critical to the business. And we want an AppSec program that empowers them to take action on findings without additional help. But even in this culture of security-conscious development, we have to minimize security friction. This requires a shift left program design (including tools and processes) where the path of least resistance is also the most secure one. For example, because our developers understand secure coding practices, we don’t intervene with open source selection unless the package is high risk or introduces licensing issues.
As a young company, we add security tooling as it makes sense from a scale and risk perspective. Given our risk exposure is mostly from open source packages vs. 1st party code, we prioritized adopting software composition analysis (SCA) early. We use SCA to prevent most open source risks from slipping into production. It’s hooked into our nightly CI/CD staging environment, allowing quick remediation with little friction and low risk of introducing a vulnerability into our production systems.
Right now our DevOps team owns AppSec across the entire business. In the next couple of years, I’d like to see that decentralized where each product team leader or staff engineer has accountability for their own AppSec — following more of a Product Security model.
Metrics that matter to leadership
At our stage of growth, we focus on three primary aspects to the security program: reducing risk, staying competitive and enabling new business lines (through compliance and product security controls), and creating a cost-effective security program. As a leader, I look for metrics indicating we’re solving what’s important quickly, and being efficient in solving the lower priority issues.
- Criticals and highs: I want us to exceed our SLAs for this category
- Mediums and lows: I look for a very efficient program where they’re getting resolved without a lot of friction.
Case study on replacing a noisy SCA
To make a dev-friendly program possible, we need an SCA that identifies packages with security or licensing issues and has a very low false positive rate. We started out with one of the “traditional” vendors in the space but found its false positive rate was very high, meaning it marked lots of findings as reachable but in fact they were unreachable in the context of our application. We frequently blocked the use of a package based on these results, but after looking into the details our DevOps team would learn there was no exposure.
Inaccurate SCA results created two problems:
- Wasted time: Manually evaluating findings to confirm reachability took time away from other tasks the DevOps team needed to perform
- Developer inefficiency: Individuals had to choose between upgrading a package (and entering dependency hell) or waiting for DevOps to investigate, when in most cases they could have proceeded with the original package
Requirements for a new SCA
When presenting the case to replace our current tool, I framed the goal as “Select an SCA that introduces the least amount of effort on developers”, with the reason being that developer time and productivity is at the highest premium in the company. To achieve this goal, I prioritized two requirements:
- Accurate prioritization: How well does the tool identify exploitable vulnerabilities, and can we easily validate the findings
User experience: How easy is it for developers to use within their regular workflows
Difficulties with upgrading dependencies is one reason it’s important for our SCA tool to be highly accurate; upgrading dependencies is time-consuming and difficult, so we want to be surgical in what gets upgraded.
Selecting Endor Labs
The decision to select Endor Labs was easy: At the time we evaluated, our last scan by the “traditional” tool claimed 100 times more reachable vulnerabilities than our first Endor Labs scan — that’s a 99% reduction in SCA noise. To be clear, finding less things isn’t inherently better. But we can be confident this was an accurate assessment of our risk because Endor Labs’ call path analysis shows exactly why a finding is reachable or unreachable. We can easily validate the claim on our own, which is important as we build internal trust in the new tool. By significantly reducing false positives, Endor Labs helps our developers focus on real threats, leading to a more efficient security process. In summary, Endor Labs delivers on its promise to make SCA way more efficient and bubble up what actually matters much quicker.
The post-sales team worked directly with our DevOps team to get us up and running very quickly, and it was easy to integrate Endor Labs with our GitHub, CI/CD pipeline, and Jira. Endor Labs ensures a good developer experience and I can quickly and accurately report on risk. For example, if I need to demonstrate how quickly we can remediate, I pull two items from Endor Labs:
- The Vulnerability Prioritization Funnel, which shows how many vulnerabilities are pending resolution
- The Findings page, filtered on what was found in the last 30 days
Then I pull Jira and GitHub from the same timeframe to show how we detected vulnerabilities with Endor Labs, governed the remediation process with Jira, and fixed the issues within GitHub. This enables me to stand behind our SLAs and assure customers that we’re a secure product.
About the Author
Idan Fast is the co-founder and CTO of Grip Security, a cybersecurity startup tackling SaaS security. Idan has over 10 years of experience in the cybersecurity industry both as an individual contributor and as a manager, ranging from Web hacking through low-level vulnerability research and development to SaaS security. He cofounded Grip to help companies solve the deep challenges of SaaS security – gaining visibility and controls over their SaaS Identity landscape.
