Build

1. 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.
2. 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?
3. 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.
4. (Note: CISO challenges are
   1. a) Those renegade DevOps people are taking risks without understanding the consequences!
   2. b) How do I secure a rapidly evolving architecture with diminishing perimeters, especially since my background is likely network security
   3. c) How do I train developers to avoid creating security vulns?

1. Vulnerabilities often discovered in production causing project delays because security finds issues just before go-live
2. Friction in the workflow causes rework and wastes time understanding context of a vuln reported today that was created a week ago.
3. 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.
4. Dependency backlog continues to grow (technical debt)
5. Unable to deploy containers and cloud as much/as fast as needed due to security concerns. (Note: we should test this assumption)

1. 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.
2. It’s extremely expensive to fix incidents and security issues in production.
3. 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).
4. Concern for risk reduces business agility that containers could enable. Containers are used broadly in POCs, but not widely adopted in production yet.

1. Application security is a natural byproduct of the dev workflow.
2. Dev fixes their own vulns without waiting for security. Security only deals with anomalies/exceptions. Security becomes a helper rather than a hindrance.
3. All of our code (custom and third party) is tested every time anything changes.
4. Less time spent remediating security flaws.
5. 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).
6. Containers would be scanned for vulnerabilities and so used more with better risk transparency.

1. We’re able to increase our velocity, reduce cycle time, and deliver greater business agility.
2. Less risk - Stay out of headlines; keep my job.
3. We’re more efficient because we fix security issues early in Dev, they don’t get to production.
4. We’re confident that our third party code is current and vulnerabilities are either removed or known risk is accepted.
5. More confident use of containers allows flexibility to reduce infrastructure costs.
6. Note: these are important to CISO, not to App Dev:
   1. Greater transparency and understanding of risk (important to CISO, not to App Dev)
   2. Better remediation plan (important to CISO, not to App Dev)
   3. Fewer vulns after dev (important to CISO, not to App Dev)

1. Need developers to own the security of their code.
   1. Broad security scans done on all code changes before it leaves the developer’s hands.
   2. Help the developer see their mistakes and how to avoid repeating.
   3. 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)
2. Security workflow for developers
   1. within the developer’s control to identify and remediate without waiting on security
   2. more easily understood results (don’t have to be a security pro to interpret results)
   3. Less context-switching, saves developers’ time
   4. Instant feedback helps dev learn secure coding practices
   5. Prioritize/resolve on security exceptions where dev needs help - prioritize security to help fix the hard problems and leave the rest to dev.
3. 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.
4. For the CISO: Overall view for security of overall risk from applications

1. Release cadence
2. Burn down of third party technical debt from security flaws
3. Fewer vulnerabilities in production code
4. Missed deadlines due to security blockers
5. number of vulns after dev (important to CISO, not to App Dev)

1. 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.
2. 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.)
3. Security Dashboard helps security focus better on exceptions where dev needs help to prioritize/resolve.

1. 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.
2. 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.)

1. Analyst reports - Forrester SCA New Tech rpt, hoping for a mention in Gartner AppSec MQ (Feb) and inclusion in the Hype Cycle (May?)
2. Industry Awards - none
3. Customer stories/case studies - CISCO, TrueBlue, BI Worldwide using and may be a reference (agreed to Forrester SCA WAVE)
4. Technical benchmark vs Fortify (WIP with NAIC) - coming soon.

1. Early funnel/Awareness/interest
   1. DevOps page: DevSecOps Solution page
   2. Security deck
   3. Blog - What our summit in South Africa taught me about cybersecurity
   4. Blog - Container security challenges (coming soon)
   5. Compliance landing page
   6. Financial Services industry
   7. Security 101 webinar
2. Middle funnel/Interest/POC
   1. Video interview with Alex
   2. Whitepaper: Seismic shift…
   3. Ungated( internal use)
   4. Gated
   5. Blog - How can teams secure applications at DevOps speed? Security Dashboards are here to help.
   6. Comparisons

What challenges do I (VP Apps) face?

1. Maintenance and integration costs, predominantly human resources costs. A large percentage of the overall IT budget goes to support teams of engineers needed to integrate and maintain a complex toolchain. An enterprise company with 1K developers needs 40 engineers just to maintain the DevOps toolchain instead of allocating these resources towards delivering business value.
2. Development is slowed/blocked by the operations team. The quintessential challenge of the pre-DevOps world is that dev teams are incentivized to increase innovation velocity by shipping new features. Operations/Infra teams are incentivized for stability, uptime and error reduction. The higher the development velocity the greater the chance for downtime and errors so these teams are at odds with each other. The VP App Dev doesn’t have enough enticing evidence or incentive to go to the VP IT Ops to advocate that to increase deployment velocity.
3. Developers doing ops Today, teams and individual developers need to spend a significant amount of time worrying about the environment where their code is deployed. Bonus: Availability of infra Teams was wait for physical servers to be procured, racked, configured, etc. the dev team is told where they can deploy by ops.

What does it look like today (problems faced)?