devopsy.kinsta.cloud

Tag: Shifting Left 2.0

  • No More Hot Potato: How Collaboration is Key in Application Security

    No More Hot Potato: How Collaboration is Key in Application Security

    Technology is accelerating at an unprecedented rate and companies with little digital footprint or experience in application security are struggling to keep up. With more and more breaches and vulnerabilities being detected in applications, people are shifting blame like it’s a game of hot potato. But it doesn’t have to be that way.

    With Shifting Left Virtual Conference rapidly approaching, Rebecca Auguste sat down with the CEO of ShiftLeft, Manish Gupta, to discuss how developers and application security teams can better collaborate to increase application security efficacy. The two talked about ShiftLeft’s strategy, how innovation and security can be at odds with one another, adopting modern solutions and everything in between.

    What is ShiftLeft? 

    ShiftLeft is a next generation application security company. As companies are moving rapidly adopting the cloud, developing software ever faster so they can deliver features to their customers and drive ever increasing revenue, in that race we are starting to leave security behind because we are still using legacy tools. The idea is we need to shift left and we have to start fixing vulnerabilities as early on as possible in the process thereby reducing our cyber risk.

    Are innovations and security at odds with each other now? 

    Historically they have been. Use of legacy technologies in a modern pipeline forces customers to choose between being agile delivering feature functionality faster or getting better at security. At ShiftLeft we are starting to show through our customer successes that that choice doesn’t have to be that way. We can become more agile and we can become more secure.

    Here are some important statistics from ShiftLeft customers:

    1. If you’re doing automated enforcement in ShiftLeft you are fixing 91.8% of the vulnerabilities
    2. If you’re not doing automated enforcement but you’re using a modern solution like ShiftLeft you’re fixing 58% of vulnerabilities in the first sprint.
    3. If you’re still stuck with a legacy solution, your team isn’t fixing 60% of the vulnerabilities ever – forget if it’s the first, second or third sprint. It becomes technical debt. 

    So why aren’t people adopting modern solutions like ShiftLeft and ditching legacy solutions?

    Legacy solutions ask developers to slow down because they have to take a few hours to go scan and dump a long list of vulnerabilities. As the developer, seeing hundreds of vulnerabilities is like a deer in the headlights. Because it’s a mountain of work, it’s easy for developers to want to ignore the problems. The question shouldn’t stop at “what are our applications consisting of?” The real problem gets solved when we start asking what do our applications contain and what vulnerabilities do they have that can be exploited, therefore how quickly can we fix them. It’s all about moving to be proactive, not reactive.

    How can development and security teams better collaborate to increase the efficacy of security with applications and software? 

    It’s extremely important for us to realize that developers are not responsible for security. Developers are measured, they are compensated to deliver feature functionality on time and to provide that feature functionality with minimum bugs. But bugs are not vulnerabilities. There is a lot of talk in the industry that developers should become responsible for application security. We aren’t there today but we can eventually.

    There are two important application personas: 

    • Application security: Application security has a mile wide and inch deep knowledge of applications and who is compensated on app security improvements.
    • Developers: Developers have a mile deep but inch wide knowledge of software because they are so focused on their own code.

    Both personas are required because application security cannot fix vulnerabilities in applications, the developer must do that. But developers aren’t going to want to do that unless that work is prioritized by application security.

    Key takeaway? Collaboration is essential to application security.

    We need to create a workflow that allows application security to meet their end goals such as: What are the vulnerabilities of an application? What are the critical vulnerabilities? How can I provide these vulnerabilities to the developer in a developer workflow without asking them to go to a different console so they can fix vulnerabilities as quickly as possible? We need to start seeing a workflow that allows both application security and developer personas to work collaboratively to improve application security.

    Shifting Left 2.0 is a two-day virtual conference taking place from 9 a.m. to 2 p.m. PDT on June 22nd-23rd that dives deep into application security in the modern tech space. To register for free and to check out the full agenda, visit the Shifting Left 2.0 website.

  • How to Analyze Your Code for Security Vulnerabilities

    How to Analyze Your Code for Security Vulnerabilities

    Shifting Left 2.0 is a two-day virtual conference taking place from 9 a.m. to 2 p.m. PDT on June 22nd-23rd that dives deep into application security in the modern tech space. Security experts share insights on topics ranging from how to measure AppSec success to what role AppSec plays in digital transformation. Software developers, security engineers, C-level business leaders and more can all benefit from the lively tech conversations at this free virtual experience. 

    Vickie Li, developer evangelist at ShiftLeft, teases her session at Shifting Left 2.0 in the Q&A below. Vickie and Suchakra Sharma, staff scientist at ShiftLeft, describe how to effectively review code for vulnerabilities and present tactics for performing an effective security code review on your applications on Wednesday, June 23rd from 10:10 a.m. to 10:40 a.m. PDT.

    You can find the full agenda and register for free at Shifting Left 2.0.

    To start off, why don’t you tell me a little bit about your role as a developer evangelist at ShiftLeft?

    My job as a developer evangelist is to help developers write more secure code. Here at ShiftLeft, we build and support ShiftLeft CORE, a security tool that helps developers find vulnerabilities in their code through SAST, SCA, and secret scanning. But a big component that goes into building secure software is to understand and remediate the vulnerabilities found by these tools. My goal is to help developers build more secure applications by learning the security fundamentals they need to write secure code and use security tools effectively.

    Your session is titled, “Intro to Code Analysis,” so I am curious what are some of the most effective ways to analyze your code for security vulnerabilities?

    I am probably giving away a bit of a spoiler here for my session with Suchakra. The most effective way of finding vulnerabilities in code is to use static code analysis, or to find security issues by analyzing source code. Techniques like dynamic analysis and penetration testing excel at finding exploitable vulnerabilities but often miss a large number of security issues. Static analysis, on the other hand, tends to be much better at finding as many vulnerabilities as possible.

    But conducting a manual code analysis on every single line of code is inefficient and not feasible in most cases. In this case, utilizing a SAST tool to scan the application and then validating the results afterward using manual code review would be the best action plan. 

    Code is really at the heart of building secure applications. With that in mind, how beneficial is it for developers to have a security mindset when writing code? 

    It is extremely crucial for developers to keep security in mind when building software. Security is a team effort by everyone: application security engineers, system administrators, managers, architects, and analysts. But when dealing with application security, developers are the ones who write vulnerabilities into code, and developers are the ones who have to fix vulnerabilities when they are found. So as developers, if we can keep security in mind during the development process, we can prevent vulnerabilities from being introduced into the code base, saving ourselves and our colleagues time and headache down the line.

    What type of security training or continuous learning practices should dev teams implement to help secure the code they write?

    Learning about security continuously is key to building secure applications. Developer security education needs to be efficient, engaging, and easy to absorb, and we need to introduce security training in a way that is relevant to everyday development work. By identifying security issues in a developer’s code, we can provide the context of the security issue and demonstrate the real-life importance of best practices.