Shipping applications at high speed must not introduce new security risks or vulnerabilities.
Challenge: Delivering secure apps (staying out of headlines) and meeting compliance requirements
What challenges do I (VP Apps) face?
Security slows down the velocity of the SDLC and blocks application delivery. The traditional incumbent solutions are cumbersome, require security to run them and interpret the results. We wait for the resource-constrained security team to run the scans and some of the scans may take days (or not complete at all). By the time a developer gets the results, they are on to another project. The security results often lack sufficient insight to tell a developer where to find the problem (line of code) or how to remediate it.
The exploding growth of third-party code - Do I know what are we using? How secure is it? How do I work off the technical debt of already-used code with newfound vulnerabilities? Are there some libraries that I should prioritize for upgrade over others?
Containers solve cloud issues and legacy app issues by making apps transportable (eliminating cloud and hardware vendor lock-in). But how to secure containers? No clear/leading solutions out there yet (Risk to my career if I make the wrong choice) and security team is unsure too. Start-up solutions do not scale.
(Note: CISO challenges are
a) Those renegade DevOps people are taking risks without understanding the consequences!
b) How do I secure a rapidly evolving architecture with diminishing perimeters, especially since my background is likely network security
c) How do I train developers to avoid creating security vulns?
What does it look like today (problems faced)?
Vulnerabilities often discovered in production causing project delays because security finds issues just before go-live
Friction in the workflow causes rework and wastes time understanding context of a vuln reported today that was created a week ago.
Business improvements (a VP App goal) take a back seat to fixing security vulns (not my goal - this is a goal of the CISO) creating adversaries between groups.
Dependency backlog continues to grow (technical debt)
Unable to deploy containers and cloud as much/as fast as needed due to security concerns. (Note: we should test this assumption)
What are the negative consequences to the business?
Risk of public disclosure of being hacked hurts our brand and our ability to serve our customers. Customers won’t trust us if our systems are insecure.
It’s extremely expensive to fix incidents and security issues in production.
The business takes on risk of cyber attack - Because business improvements are the goal of app dev, they use more third-party code and worry about the technical debt and risks later (that is for Security to figure out).
Concern for risk reduces business agility that containers could enable. Containers are used broadly in POCs, but not widely adopted in production yet.
What does it look like if a magic wand were to solve it today?
Application security is a natural byproduct of the dev workflow.
Dev fixes their own vulns without waiting for security. Security only deals with anomalies/exceptions. Security becomes a helper rather than a hindrance.
All of our code (custom and third party) is tested every time anything changes.
Less time spent remediating security flaws.
All third party code would be identifiable, with understood risks. The technical debt would be prioritized by risk including severity and scope of use (potential business impact).
Containers would be scanned for vulnerabilities and so used more with better risk transparency.
What would be the positive outcomes for the business?
We’re able to increase our velocity, reduce cycle time, and deliver greater business agility.
Less risk - Stay out of headlines; keep my job.
We’re more efficient because we fix security issues early in Dev, they don’t get to production.
We’re confident that our third party code is current and vulnerabilities are either removed or known risk is accepted.
More confident use of containers allows flexibility to reduce infrastructure costs.
Note: these are important to CISO, not to App Dev:
Greater transparency and understanding of risk (important to CISO, not to App Dev)
Better remediation plan (important to CISO, not to App Dev)
Fewer vulns after dev (important to CISO, not to App Dev)
What capabilities are required to make this happen?
Need developers to own the security of their code.
Broad security scans done on all code changes before it leaves the developer’s hands.
Help the developer see their mistakes and how to avoid repeating.
The ability for developers (who write the code) to self-identify vulns and understand what they are and how to remediate security problems earlier in SDLC. (empower the developer)
Security workflow for developers
within the developer’s control to identify and remediate without waiting on security
more easily understood results (don’t have to be a security pro to interpret results)
Less context-switching, saves developers’ time
Instant feedback helps dev learn secure coding practices
Prioritize/resolve on security exceptions where dev needs help - prioritize security to help fix the hard problems and leave the rest to dev.
Visibility into the security of 3rd party code and containers and all related components of the application, infrastructure, etc. Confidence that their risk is understood and eliminated where possible.
For the CISO: Overall view for security of overall risk from applications
How would you measure success (metrics)
1.Number of hrs dev spends removing vulns (immediate should be much more efficient)
Release cadence
Burn down of third party technical debt from security flaws
Fewer vulnerabilities in production code
Missed deadlines due to security blockers
number of vulns after dev (important to CISO, not to App Dev)
How does GitLab help solve the problem?
Automation of security testing, including SAST, DAST, dependencies, containers and license mgmt of third party code, before the code leaves the developer’s hands. DAST scanning is done before code is committed via the GitLab review app feature.
Single SDLC application embeds security testing into developer’s natural workflow with understandable results reported to the developer with remediation advice and line-of-code detail enabling them to remove the vulnerability before their code is merged with other code. (note: for CISO, this results in far fewer vulns for security team to manage.)
Security Dashboard helps security focus better on exceptions where dev needs help to prioritize/resolve.
Why are we better than the competition?
Single app for the SDLC application to avoid stitching together and maintaining a devops toolchain that must integrate with multiple security tools (efficiency for both dev and app sec teams) - no integration to support/maintain, cost, skill sets.
SAST, DAST, Container scanning, dependency scanning and license mgmt ALL done IN the MR pipeline for EVERY code commit, presented to the developer. No other app sec tool can perform a DAST scan before the code is committed. (The closest capability would be IAST which is a separate tool purchase.)
What are the proof points that prove this?
Analyst reports - Forrester SCA New Tech rpt, hoping for a mention in Gartner AppSec MQ (Feb) and inclusion in the Hype Cycle (May?)
Industry Awards - none
Customer stories/case studies - CISCO, TrueBlue, BI Worldwide using and may be a reference (agreed to Forrester SCA WAVE)
Technical benchmark vs Fortify (WIP with NAIC) - coming soon.
