devopsy.kinsta.cloud

Author: Gary Robinson

  • DevSecOps Deluge: Choosing the Right Tools

    DevSecOps Deluge: Choosing the Right Tools

    In the last few years, DevSecOps has become the security process of choice for many forward-thinking enterprises. 

    These organizations have come to understand that fixing bugs in the latter stages of product and application development offers no favors to anyone but cybercriminals. So, they have overhauled traditional processes and united development, operations and security teams to form DevSecOps where the teams now work in tandem, cooperating to embed security into the entire process of application and software development.

    The benefits of this are clear; finding and fixing bugs early closes doors on cybercriminals while bringing peace of mind, cost savings and better products to customers. However, one of the challenges many organizations face when transitioning to DevSecOps is making the process seamless, ensuring it doesn’t slow down the software development life cycle, make security checks more cumbersome or cause frustration among teams. 

    Security teams need to ensure their DevSecOps program is delivering value to the culture of the organization while speeding up time-to-fix, capturing the right metrics, and categorizing and prioritizing issues based on their risk so that nothing goes live that could cause major damage.   

    Additionally, they also need to select the correct DevSecOps toolkit to carry out application security testing while ensuring the tools easily integrate into software development and can be used across multiple projects. When identifying tools for testing, DevSecOps teams are often overwhelmed by the huge range and volume available, which makes choosing which ones to use and learning how to use them a minefield, even for those with the right training and know-how. 

    A DevSecOps automation program needs lots of technical tools and cultural aspects to come together to make it work. Security teams need static analysis tools to check the code, third-party library analysis to check the dependencies, separate analysis to check the infrastructure-as-code (IaC) configuration, scanners to check containers for issues, tools to test the running system, cloud security checks and infrastructure testing for patches and ports. They also need to match these tools up to the right technology each team is using and keep up with the constant changes.

    Given all of these complexities, how can DevSecOps teams overcome these challenges and build out an effective DevSecOps program with the correct toolset? 

    Here are some top tips to help them along the way.

    Keep Security Processes Flexible 

    Your teams are going to be using different technology stacks, different languages, frameworks, and so on. If you tie your process too tightly to a few tools, it’ll be harder to slot in new checks when things change. Remember that the aim is a consistent, repeatable security process with the right visibility—the technical tools feed into that, but they are not the whole process. What security checks will you need in 12 months that you don’t have now? What about 36 months? These are questions that must be asked continuously. 

    Automation is Your Friend

    If development pipelines are running smoothly and automatically, then any manual security steps are not going to fit in with the process. Automating security tools together—from orchestrating their running to aggregating their responses and managing issues—will save a lot of time and give you the results you need in line with your releases.

    Keep an Eye On Your ROI

    It’s very common for big-ticket commercial tools to be underused; you have the licenses for repeated testing and you have frequent code drops, but the processes or the integrations mean testing isn’t applied as often as needed or the results take time to collect and process. Explore ways to bring commercial tools easily into the existing processes.

    There’s No Such Thing as a Free Lunch

    The open source community provides great security tools, but remember: There is a cost associated with the time it takes your teams to use them and to manage the outputs. From developers learning how to run them to the time it takes to actually run them or extract the results or manage false positives—these aren’t free. A ‘free’ tool that costs two hours of work every release might not be worth it.

    DevSecOps is All About Collaboration

    Weaving security checks into development processes, CI/CD pipelines, ticketing systems and sprint meetings help security to be part of the development process, but not every developer is—or wants to be—a security expert. Think about how the aims of development and security can meet in the middle. How can developers include security without much effort or thought? How can security help supply the tooling and help triage issues in developer pipelines? How can the process conform to auditors’ tools and with correct profiles, not just turned down to zero to avoid reporting issues? How can security add value at scale to help developers fix issues faster regardless of the tooling being used?

  • How to Seamlessly Transition to DevSecOps

    How to Seamlessly Transition to DevSecOps

    In the last few months, the cybersecurity world has been taken by storm following the discovery of the Log4Shell vulnerability. The zero-day had the potential to put much of the connected world at risk and left security teams scrambling to quickly apply security patches to software just before Christmas 2021.

    As a result of the chaos caused by Log4Shell, many organizations kicked off the new year by carrying out security assessments to identify ways to improve detection and mitigation of future vulnerabilities. One approach that is gaining a lot of attention is DevSecOps.

    DevSecOps introduces and automates security in the earlier phases of the software development life cycle rather than bolting it on at the end. The approach saves money, saves time on tedious manual tasks, helps organizations meet regulatory compliance requirements and significantly reduces the risk of critical security bugs being found after an application’s final build.

    However, when it comes to kicking off DevSecOps projects, there are a few challenges application security teams need to overcome first to ensure their programs fit seamlessly into CI/CD pipelines.

    DevSecOps Isn’t Simple

    While moving to DevSecOps delivers organizations clear benefits in the way of security, one of the key concerns for business leaders is that it slows down the delivery pipeline of software and applications. Today, being an agile software delivery machine is essential and a critical part of an organization’s survival, so no business leader wants to put development velocity at risk because of security testing.

    Application security teams are tasked with ensuring DevSecOps fits seamlessly into software and application delivery, without causing delays or adding more pressure onto already over-stretched DevOps teams. As a result, they need to identify which tools are needed for security testing and integrate them into development stages seamlessly as well as which ones can be automated and which can scale to meet the demands of CI/CD pipelines.

    The great news for application security teams is there are hundreds of security tools available; the bad news is choosing which to use and learning how to use them is a minefield, even for those with the right training and know-how.

    A DevSecOps automation program needs lots of technical aspects to come together to make it work. Security teams need static analysis tools to check the code, third-party library analysis to check the dependencies, separate analysis to check the infrastructure-as-code configuration, scanners to check the containers for issues, tools to test the running system, cloud security checks and infrastructure testing for patches and ports. They also need to match these tools up to the right technology each team is using and keep up with the constant changes.

    So, what are the most important features that application security teams should look for in DevSecOps security testing tools?

    Tips for Approaching DevSecOps

    Security teams need a way to manage their security tools so that tedious tasks are removed but collaboration with development teams is streamlined. They need a platform that handles the automation process, flags only the issues they want to flag and presents them in a way that is accessible to everyone, from execs to board members to developers.

    You’re Going to Need a lot of Security Tools

    We commonly see teams using 10+ tools to cover the needed checks, so be prepared to chain together multiple security tools. Some to check each source code language the development teams are using, more to check your containers, cloud setup and dynamic testing against the staging system, etc. 

    Tip: Be prepared to do some up-front analysis to establish which security tools are going to make up your DevSecOps initiative.

    Think of the Day-to-Day ‘Security-as-a-Service’

    How are you, or your teams, going to work with the security tools? Is someone going to check the output of 10 tools in every build? Are they going to compare each set of issues against the last to see what’s new? How will they handle the open source tools that don’t track false positives? This is a major part of the DevSecOps process, and a very common place where we see processes fail—if the automation of the tools leads to awkward handling of vulnerabilities, it’s doomed.

    Tip: Have tools send their vulnerabilities to a centralized store for ease of use.  

    Tip: Track the difference between runs so it’s easy to see new and high-risk issues.  

    Tip: Think of how developers and security teams can more easily collaborate on issues.  

    Tip: Think of how false positives, duplicates or non-issues can be handled and tracked so developers are not flooded with the same issues over and over again.

    Be Flexible With Your Security Tools

    No matter how you intend to integrate security tools, know that different teams are going to need different tools. Some will use Docker, for example, others won’t. Often, different development teams end up working in different coding languages, which means there will also be different security tools required to scan. Some teams will be up and running with DevOps, others won’t be there. Keeping security testing consistent and repeatable is difficult.

    Tip: Whatever DevSecOps platform you use or build, make sure you can slot in the right tools for the right job. If you’re too rigid, you’ll waste time running tools and dealing with nonsense issues and no one will want to play with you.

    Work With the Existing SDLC Environment

    If your teams use Jira to track development tickets, for example, work with that and have new issues entered and tracked there. If they use five different DevOps pipeline platforms, be prepared to integrate and work with each of them. If you have metrics for security, know how you’re going to track changes per repo, project, team, division, etc. for each pipeline run and all the various categories of tools.

    Tip: Run your DevSecOps implementations where your development teams are, work with their systems and make security an easy extension of their existing workflows.  

    Tip: Be able to track historical metrics across categories of issues and tools, so you can show what good progress you’ve made, and where your security investments are (and are not) working.

  • Bridging the AppSec and DevOps Disconnect

    Bridging the AppSec and DevOps Disconnect

    Research estimates that cybercrime is going to cost the world $10.5 trillion annually by 2025, so it is no surprise that cybersecurity has become a top priority for business leaders. 

    Today, security teams are striving to harden their systems against cyberattacks and improve their resilience through more employee security training, incident response programs and the implementation of technology to monitor and detect threats. 

    Many organizations are also adopting a shift left security strategy, where security is being addressed earlier in the application development life cycle. These organizations are realizing that finding security issues in their software after it’s released is much riskier and more costly. After all, the longer a bug is in the wild, the longer an attacker has to find and exploit it. By implementing a shift left security strategy, the window of opportunity for an attacker decreases or can be completely removed if a security issue is addressed in the development stages, while also offering organizations significant security benefits and cost savings. 

    Shifting left is a security testing strategy where DevOps and security teams work in tandem to identify and address vulnerabilities during early development stages. This process significantly improves security as it means vulnerabilities are identified and mitigated before they are introduced to the enterprise environment.

    However, one of the biggest challenges organizations face when adopting a shift left security strategy (DevSecOps) is encouraging security teams and DevOps teams to work together.

    Encouraging AppSec and DevOps Collaboration

    Until recently, DevOps teams and AppSec teams were completely siloed. DevOps teams worked on accelerating the speed at which applications are released into the enterprise; application security teams only got involved in the later stages. However, this process has caused security concerns, particularly as more organizations move to agile development. 

    When security teams eventually got their hands on new applications and updates, security flaws were inevitably found that caused delays and friction with DevOps teams. 

    However, as organizations begin to embrace DevSecOps and shift left strategies, these two previously siloed teams are being forced to work together more closely. So, how can the friction be reduced and the disconnect bridged?

    Culturally, some ingrained attitudes and behaviors challenge the success of any DevSecOps efforts. Security teams have seen DevOps processes accelerate the speed at which software is delivered, but without security considerations, while DevOps teams experienced security slowing down processes and giving inconsistent results and feedback on security issues. Each party has their own manager to please; their own set of metrics that they’re measured against and a priority list as long as their arms already. Both teams follow different processes and, crucially, use different tools. DevOps can’t get around the security tool complexity and lack of integration with their existing toolset and security teams have no control over the CI pipeline to best implement security assurance.

    One of the best ways to overcome this friction is through better technology, process and culture that enables collaboration between teams. First, DevOps teams do care about security, but it might be lower on their priority list. Security teams must understand that DevOps teams care about code, quality and efficiency. They are not security experts and just because an organization is shifting left doesn’t mean they need to become one. Instead, organizations should implement tools for DevOps where security checks can be easily embedded.

    So, what can organizations do to improve the collaboration between AppSec and DevOps teams to achieve DevSecOps?

    DevSecOps is a culture and it requires a shift in thinking. Security teams and DevOps teams need to understand each other’s priorities and understand that by working together they are improving the overall security of the organization and decreasing the risk of cyberattacks. Does the DevOps team understand the potential risks a vulnerability could have on the organization overall? If not, security teams need to educate them.  

    Security automation tools offer great support when organizations are moving to DevSecOps, as they allow bugs and vulnerabilities to be flagged automatically as applications are being developed. This will allow them to be addressed before services go live; however, because they generate frequent alerts, this could add to DevOps’ already busy workloads. By deploying tools which can be synced with CI/CD pipelines and provide custom advisories so DevOps teams can address bugs themselves without having to ask AppSec teams, this can significantly speed up the process, reduce friction and ease workloads.

  • Overcoming Challenges to Automating DevSecOps

    Overcoming Challenges to Automating DevSecOps

    In the last few years, DevSecOps has been widely adopted among organizations looking to get proactive with their security. Traditionally, development teams would continuously implement and deploy new applications into the enterprise and security was an additional bolt-on at the end. 

    However, as the threat posed by cybercrime has increased, organizations have been ‘shifting left’ with their security and weaving it into the beginning of the development life cycle. 

    This offers significantly increased security benefits and means software vulnerabilities can be identified and remediated before they are exposed to the enterprise. The one drawback is around the additional time this takes. As a result, many organizations are also looking to automate their DevSecOps processes. 

    Automation is a critical feature of DevSecOps as it improves efficiency, cuts costs and can streamline operations. However, to get the most out of DevSecOps automation so it delivers real value to the organization, there are several challenges that must be considered first. But what are these challenges and how can they be overcome?

    How to Approach DevOps Security Automation

    When you first move to security automation, you’ll find some security tasks that can easily be automated and others that are harder to fit in. DevSecOps teams will need to use many tools to cover all their bases, but no one wants teams checking lots of different tool outputs. Making it easier to see what’s going on and where risk lies by consolidating security tools and results in a central platform is the way to go. This makes life easier by giving a single pane of glass. Everyone generally agrees that DevOps teams must adopt cybersecurity best practices, but testing takes time. Development teams don’t have time to learn, use and check lots of security tools on top of their existing workload. Automated solutions get to work without any real need for maintenance or management. These solutions trigger tools to work at the right time depending on the outcomes found without any manual input needed. This gives you and your team valuable time back to focus on other important matters.

    Fitting DevSecOps Into Secure CI/CD Pipelines

    The goal of CI/CD pipelines is fast delivery of build and release steps, typically through automation. A key goal of DevSecOps is to alert someone to a new problem as early in that automated process as possible. You need to develop solutions that don’t overwhelm CI/CD pipelines, yet allow flexibility for differing tech stacks, security tools and environments. What you need to ask is, have the latest changes caused any new and important security issues that should be reported before going live?

    Doing DevSecOps Without Constant CI/CD Changes

    Trying to manually run security tools on your entire application source code each day can be time-consuming and hinder your ability to keep up with daily changes. For security checks to keep pace with code delivery in a CI/CD environment, security automation is a must. Security products need to integrate into the development pipeline and enable both the development and security team to work together instead of just throwing things over the fence to each other. 

    Focusing on Issues Raised for Faster Remediation

    All the artificial intelligence and machine learning (AI/ML) in the world isn’t going to remove non-issues better than a manual triage, so here we recommend being resigned to getting stuck. Treat the first run of a set of security tools as a normal security test. Expect hundreds of issues and be prepared to go through them and mark the false positives, duplicates and issues that just aren’t important right now. But do this with the expectation that you’re creating a baseline against which your future pipeline scans can be measured so you’re only alerted to new important issues. By automatically managing and recording the lists of real issues existing in every DevSecOps pipeline run, we can then concentrate on the differences. These new issues need to be flagged and then made easily visible and actionable for all teams.

    Running Multiple Security Tools in CI/CD

    DevSecOps includes setting up many automated security tools to cover the many types of security issues that need to be checked for. Many organizations run multiple security tools. However, as the number of security tools grows and the DevSecOps processes become more complex, many companies then realize the hardest challenge is to make sense of all of the test results within a short period of time. For some companies, this task of bringing together the results from all of these tools is a full-time job, and one ripe for automation. 

    Triaging Security Issues

    False positives and nonsense issues are consistent problems for using security tools. Removing these gives better results and increases the chances that development teams will have a better relationship with DevSecOps processes. Organizations should build a list of issues that don’t need to be actioned and also use automated security tools to flag new issues and differentiate them from the previous backlog of issues. Automating the ‘best fixes’ across all issues also speeds up fix times, while reducing the workload on security teams. 

    Mapping Security to Development Processes

    Dev and DevOps teams are under pressure to get pipelines running smoothly and don’t want security slowing things down or complicating it. By automating security testing in such a way that it can easily handle changes in repos and containers, organizations can overcome this challenge without compromising security. 

    Risk Prioritization

    DevSecOps will increase the number of issues found as well as the speed with which they should be handled. In reality, only a small number of issues will pose a massive risk to the business. Being able to pinpoint the really big issues in real-time helps security know the big risks are being covered and allows developers to focus on the real issues, not lots of small bugs. You can also intelligently determine the changes in risk for quick and automated decisions in the CI/CD pipeline without slowing down the development team.