Forem: Gary Robinson

AppSec and DevOps: How to bridge the DevSecOps Disconnect

Gary Robinson — Tue, 28 Jun 2022 07:14:08 +0000

It’s a tale as old as time: developers want to ship an app but are lambasted with security requests, and security teams want to secure an app but are brought in too late to do their job without knocking some heads in the process. The ensuing result is usually insecure code and frustrated teams.

The time is ripe for rethinking how developers and security teams work together. It’s no longer kosher to have two integral teams at odds with each other in a time when all eyes are on speed and safety. Collaboration is key, and to get to a place where seamless collaboration happens, it’s important to understand and overcome the challenges faced on both sides.

WHO OWNS APPSEC?

Let’s start with the obvious: Who owns application security? Developers will tell you they’ve gone to great pains to ensure every line of code is as secure as they need it to be. Security teams will tell you they haven’t gone far enough. This clash of opinions stems from a mutual misunderstanding of the other’s function. We commonly refer to this as the DevSec Disconnect. Giving problems a catchy name is great and all, but with teams operating in such a way, how do we go about bridging the gap? We’ll touch a bit on this later, but communication and collaboration built into the development process is key.

Zooming into the misunderstanding on both sides, we can see exactly how it is such a source of frustration. No one team can have full oversight if developers lack the time and technology to close security gaps; while security teams are notoriously understaffed and tend to lack the full development cycle view.

LACK OF VISIBILITY AND COMMUNICATION

Human error is still the biggest threat to application security, and 90% of cyberattacks are aimed at software. Faced with this status quo, you would think that teams would share knowledge and talk to each other. But that’s not necessarily happening across the board. DevSecOps technologies have yet to reach proper market adoption levels and organisational inertia is one of the main obstacles to DecSecOps implementation.

A lack of visibility also challenges the role of analytics and measurement. Security tools generate reports and tasks to get software up to scratch, but with a cohesion gap, how does anyone make sense of the data, and who is accountable for it?

PEOPLE, PROCESSES, AND PRIORITIES

Culturally, some ingrained attitudes and behaviours challenge the success of any DevSecOps efforts. Security teams think developers don’t care about security, developers think security people are naysayers and give inconsistent advice. Each party has their 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 operate at different levels, follow different processes and crucially, use different tools. Developers can’t get around the security tool complexity, and security teams have no control over the CI pipeline to best implement findings.

We also see different meanings and weighting of security risks between developers and security teams. What’s an absolute necessity to one might be seen as a nice-to-have to the other. This leads to a mismatch in the prioritisation of risks and disagreements about where to focus efforts.

There is a silver lining and a caution. GitHub’s 2021 Global DevSecOps Survey found some good news and some not so good news.

Good news: 70% of security team members say security has shifted left
So-so news: over three-quarters of the security team continue to think devs find too few bugs too late in the process

The Developer/Security relationship has come on leaps and bounds, but there’s still a long way to go.

DEVSECOPS AUTOMATION: BRIDGING THE DEVSEC DISCONNECT

Shifting security left has been at the forefront of every software company’s plans for the last few years. There is an industry-wide appreciation for the need to get security involved at all levels of the SDLC, with no exceptions.

But goodwill only gets DevSecOps so far. According to a 2019 DORA report, only 31% of the top organisations doing DevSecOps properly have been able to automate security within their environment, and 70% of organisations lack adequate working knowledge of DevSecOps practices. Without investing time to instil organisational-level understanding and best practices, and money into the tools to make light work of it, DevSecOps maturity levels will stagnate.

DEVSECOPS IS A CULTURE

Imagine a world where high-performing teams spot vulnerabilities early and eliminate false positives. A universe in which developers become security-aware, and security teams reduce real risks early in the life cycle. When collaboration starts, development and security teams begin to confidently ship safe software faster.

SOLUTIONS START WITH COLLABORATION

DevSecOps automation and orchestration platforms like Uleska can help to improve collaboration between developer and security teams by streamlining testing and correlating results. They can fundamentally change the way development and security teams work and improve the organisation’s DevSecOps maturity.

If you want to learn more about the challenges facing DevSecOps today, check out our in-depth guide.

Adding risk prioritisation to your pipeline security

Gary Robinson — Tue, 21 Jun 2022 09:38:35 +0000

DevSecOps increases the number of issues found and the speed at which they’re to be dealt with. In reality, only a small number of issues will pose a massive risk to the business. Unfortunately, security tools only give part of the risk picture when they return an issue.

That’s why being able to pinpoint the really big issues, in real-time - automatically - helps you know the big risks are being covered. It also helps ensure the development team can focus on important issues and not lots of small bugs. Let’s look at this in more detail.

The problem with security issues
The implications for DevSecOps
How to apply risk-based testing to software security issues
Why the Uleska Platform uses the FAIR Institute methodology

THE PROBLEM WITH SECURITY ISSUES

The problem with security issues is they are not created equal. In any list of 1,000 security issues, there’ll be some that would put the company out of business if breached, as well as some that wouldn’t even raise an eyebrow.

This isn’t just a technical discussion, but a business discussion as well. Let’s take a look at an example. If we were to pretend we have found two SQL Injection issues in two of our systems, these SQL injections would be exactly the same from a technical standpoint. However, let’s look at the context of the systems:

System 1:

Internal application
Used for cleaning staff to order which rooms are going to be cleaned
About four users
No sensitive data

System 2:

External application
Used for processing financial and PII data core to the business
About four million users
Lots of sensitive financial and personal data

In this example, we have exactly the same technical SQL issue, which would likely be flagged by security tools in exactly the same way (usually high or critical). However, there’s no real business risk from system 1 while the business risk from system 2 could end the company.

If system 1 were breached, we’d likely never hear about it - and who would want to breach it? For system 2, this is similar to the TalkTalk hack from 2015, which resulted in large fines.

However, from a pure tooling point of view, both SQL issues would likely have been reported with the same severity, meaning security and development would have needed to handle both the same.

THE IMPLICATIONS FOR DEVSECOPS

1. Release risk (new issues)

When new issues are found in the latest pipeline security scan, what is the impact or risk of those? Should we stop the build/release, or let it through? This is important for security policy decisions. If a few new issues are found but are very low risk, then we may be able to proceed with the release to get the new functionality out and apply fixes later when time allows.

However, if there are major issues with an application running sensitive data to millions, then we’d likely make a different decision. We also want to automate as much as possible here, given the scale of issues that are going to be reported every day through automated testing.

Processes (and tech) that stop the build/release based simply on the existence of any vulnerability, regardless of risk, end up being turned off or ignored as they are too noisy. There’s usually some security issues in the backlog, they’re known about and going to be addressed, but shouldn’t stop the release.

On the other hand, adding risk-based analysis of each new issue in the pipeline means better decisions can be made (or automated) for go/no-go.

That’s why making this decision as easy and as automated as possible is not only an advantage but is likely the only way it will succeed in DevSecOps.

2. Overall risk reduction (backlog issues)

Many companies will have thousands of backlog security issues on their lists, yet as we’ve examined they’re not equal in terms of risk. What a company, especially stakeholders, wishes to do, is to effectively and efficiently reduce that risk over time and be seen to do so.

Let’s say we have two issues in the backlog that each takes one day to fix. If one issue was classed as $1million in cyber risk and the other $1,000, then you fix the $1million risk first. If you expand this to the thousands of issues in the organisation, then applying risk metrics to them means you can burn down around the top 10% of the highest risk issues and dramatically reduce your overall risk.

Wrapping this risk prioritisation into DevSecOps which then scales into all teams becomes a very effective way to both reduce - and keep reducing - the risk to the business.

HOW TO APPLY RISK-BASED TESTING TO SOFTWARE SECURITY ISSUES

Around the world, many regulations are focusing on the risk of issues, as well as the technicality of them. For example, the NYDFS Cybersecurity Regulation focuses on regular risk assessments. NIST has also recently announced support for the FAIR Institute cyber value-at-risk methodology to determine which security issues pose the greatest risk to the business.

There are a few ways to apply risk-based testing to software security issues. We prefer the FAIR Institute (as used by NIST) methodology which combines:

The technical aspect of the issue - i.e. how easy is it to exploit, what effect does it have on availability, integrity and confidentiality? Think CVSS v3 aspects and you're effectively there.
The nature of the system containing the bug - i.e. is it online or internal, how many users does it have, what assumptions could you make on the skill of those users to breach the system?
The data contained in the system - are there millions of PII, financial or healthcare records? Think about how people only rob banks because that’s where the money is.

By combining these inputs about a system and its bugs and applying the FAIR Institute methodology, you can quickly and automatically get strong risk estimations of the impact of each bug. When you have this, you can apply thresholds during the build/release (i.e. if risk of the issue is below X, continue, if it’s higher, take some action to alert). Historically, you can simply order backlog issues based on the cyber value-at-risk number calculated.

As the FAIR methodology describes, issues are assigned a dollar value risk range to represent the cost to the business of the risk. This is a combination of the impact, if the issue was breached, and the likelihood of the breach occurring on the system in question.

That’s why our SQL Injection without any sensitive information and low number of internal users isn’t much of a risk, while millions of sensitive data items exposed to the internet is a bigger dollar risk.

WHY THE ULESKA PLATFORM USES THE FAIR INSTITUTE METHODOLOGY

The Uleska Platform has implemented the FAIR Institute methodology into its risk algorithms so that each issue returned from security tools can have risk analysis automatically applied. This means as soon as we have the issue, we can flag the dollar risk of the issue and pass this back to CI/CD systems for decision making, flag in our UI and reports and track historically for metrics.

To do this, the Uleska Platform extracts the CVSS and similar information from the security issues returned by the various security tools integrated and combines them with quick-to-configure descriptions of the projects.

For example, a new application or project can set the range of expected users - whether it’s tens, hundreds or millions - the nature of data processed (including financial, healthcare and personal data) and some items on the project environment.

With this, the FAIR methodology is quickly applied so each issue can have a dollar risk associated. When that issue is fixed, the project shows the risk improvement. Finally, when decisions are being made about what features and security fixes are to be scheduled into the next sprint, the dollar risk can help make the case for certain bugs to be fixed or not.

To learn more about the challenges of automating DevSecOps and how to overcome them, take a look at our playbook.

[Live Webinar] Shift Left or Collaborate with Security?

Gary Robinson — Thu, 09 Jun 2022 09:26:10 +0000

Hey folks! Hope you're all doing well.

Here's an invitation to all the devsecops community here in dev.t for one of our upcoming webinars 👋

🗓 Thursday, June 30th 2022
⏰ 8:00 PM (BST)
🔗 Registrations

In this webinar Laura Bell (Founder & CEO of SafeStack, co-author of Agile Application Security and Security for Everyone) and myself will discuss the topic of ‘Shifting Left’ when it comes to software security, the challenges it can present, and better models that exist to share the load of security in today’s agile SDLCs.

There’s been lots of talk of ‘Shift Left’ when it comes to security - allowing outnumbered software security teams to move security tasks onto development teams, earlier in the lifecycle, to increase speed and scale of AppSec tasks. Many companies have taken steps to shift security left, but ran into problems of increasing developer friction and adding no real value to security programs.

With many security teams busy, and software releases speeding up, there’s such a strong need for security to run smoothly and at pace with development & CI/CD pipelines, being better weaved into developer practices. Here, Laura and Gary talk through how SafeStack and Uleska have become partners to help companies improve their training and centralisation of security tools in the SDLC, in ways that focus on collaboration and sharing expertise between teams, over passing out security responsibilities to dev teams.

This webinar covers:

What’s wrong (and right) with ‘Shift-Left’ security, where are the pain points the industry is seeing?
How you can weave security throughout your SDLC from idea to maintenance with SafeStack’s ongoing secure development training, including their latest course, Introduction to DevSecOps.
How can you bring more collaboration into security checks (tools) so that security and development teams can amplify their skills and increase the speed and quality of security, without slowing anyone down?
Your Q&A, what questions do you have on software security training and automation?

Have questions now? Send them to hello@uleska.com with the subject ‘Webinar questions’ and we’ll be sure to answer them during the presentation.

We look forward to seeing you there!

🔗 Register here

The speakers

*Laura Bell *(SafeStack Founder and CEO, co-author of Agile Application Security and Security for Everyone) specializes in bringing security into organisations of every shape and size, with a focus on building security skills, practices, and culture across the entire engineering team.

*Gary Robinson *(Uleska Chief Security Officer, former OWASP Global Board member) shares his experience of automating security tools in the SDLC, increasing collaboration and sharing across teams, and building a culture around security automation.

About SafeStack

SafeStack is a community-centric online training platform that takes a flexible, people-focused approach to ongoing cyber security education at a time when it’s never been more needed.

By teaching software development teams to weave in security from idea to maintenance, as well as providing cyber security and privacy awareness training for the wider workforce, SafeStack's training programs offer a comprehensive way of protecting your people, systems, and data in an ever-changing world.

About Uleska

Uleska is a platform that helps you manage your application security at scale. By automating and centralising your preferred security tools within CI/CD.

Bringing security, DevOps and development teams together, Uleska minimises your manual tasks so application security takes less time, less cost, and can scale. This means you can focus on the issues and metrics that really matter.

🔗 Register here

Mapping security automation to how development works

Gary Robinson — Thu, 26 May 2022 11:36:23 +0000

All teams present in the app development process have pressures on them to get work done fast and efficiently. With DevOps processes and CI/CD pipelines humming, the last thing you want is for security to slow things down or complicate the existing workflows.

We’re taking a look at secure SDLCs and the CI/CD pipeline - and how security tech and processes can better fit into the current development way of working. Ultimately, making things simpler and better for developers.

How current security testing causes further work for teams
Challenges faced
How to effectively work through the issues
How the Uleska Platform works through the issues

HOW CURRENT SECURITY TESTING CAUSES FURTHER WORK FOR TEAMS

The way security testing is conducted and modern software development is handled aren’t perfectly aligned. This clash of approaches can cause further work and delay between security and dev teams.

For example, when it comes to container security, there are lots of good commercial and open source security tools that can take a container or a registry and examine them for known security vulnerabilities.

Typically, security tools approach this task on an image level. They take the image, find the vulnerabilities, return a list of them and the job is done. If you update the image or wish to check the image again after a period of time to know if any new vulnerabilities have been detected by the industry on this image, you can run the image through again.

If you have a registry, the security tool can look at all the images and tags and report on all of them. This can result in a large list of vulnerabilities - issues that were unforeseen and now have to be addressed.

Developers will work with container images differently. Each image is a resource and that image may be used on one project, many or it may not be used at all. But how do you know if a particular image is used in a project?

While members of the development team may not be keeping track of all the images they use, it’s likely in the logic of the projects’ CI/CD pipeline, where the image names/tags are specified during the build/release.

So, on one hand, we have reams of security issues reported against images or the registry. On the other hand, we have development projects that use some subset of those images.

CHALLENGES FACED

This poses a few challenges:

Simply looking at the lists of issues from the security tools doesn’t give the right, holistic picture. Many of those issues will never come to light due to the images not being used. This time wasted on fixing issues for containers that aren’t used is time that could be spent on further development.
Not knowing how many times a container is actually used in projects can hide the effect any issues would have. Remember, you’ll have lists and lists of issues to work through and simply working down through the individual risk or CVSS of each issue is the wrong approach. It could well be that an issue that’s not top of this list exists in a container that’s used by 50 projects, which should be prioritised to be fixed first.
The real risk of a security vulnerability isn’t just based on the technical bug but includes the sensitivity of the data processed (PII, financial, healthcare) and the scope of the project. For example, is it used by five internal people or 50 million people around the world?

HOW TO EFFECTIVELY WORK THROUGH THE ISSUES

For each of the issues found, knowing where - or if - the affected component is used, what it’s used to process and the scope of each project using it, is the best way to effectively work through the issues from top priority to bottom.

This disconnect is exacerbated by codeline versions - with libraries and containers that are likely to change often. If we’re adding extra steps in our processes to onboard new codelines or containers into lots of security tools on every change, then that’s quickly going to become an impossible task.

Dealing with a security check on the image/tag

Let’s look at another aspect. Let’s assume we’ve set up our pipeline to security check the image/tag when doing the build. In this case, we have a good chance of finding issues early, but we’re going to waste a lot of cycles checking the same image over and over again. This poses a few issues.

Checking the image again and again

If this image is used by 20 projects and we do a release a day, we’re going to check that same image 20 times each day. This not only delays the security results in real-time but likely costs more due to security tools charging for the time they’ve analysed the containers they’re given.

It can be difficult to align these. Most security products ask you to onboard items to be tested (such as containers, repos, URLs and EC2s, for example) so they can test and report on them. However, doing this initial onboarding can be difficult, especially if the dev team doesn’t have a full understanding of what codelines and images they’re using.

Even if they do, it’ll quickly get out of sync when someone updates the project codeline or image in CI/CD and doesn't update the onboarded profile in the security tool - you’ll now be reporting security against the wrong thing.

More regularly, we see the truth of what assets are used in a software project that is held in the pipeline, that’s where the codelines, URLs, images and boxes that are actually used are configured. Configuring security tools outside of this will lead to misalignment and reporting on issues/risk that doesn’t match up to the reality of the software project.

Extra work for the Dev team

Checking this security and dev context also adds extra tasks onto the development teams who are making these changes, frustrating people further.

Things change. Teams introduce new technologies, frameworks and libraries. New teams start using other coding languages. The business buys another company that develops in ways no one else has used before.

Typically, the security tooling is tied to the tech being tested. Tools that check AWS for security don’t tend to work on GCP or Azure. Tools that check Python code won’t find anything in C++. Even commercial tools that cover many languages will have differing levels of coverage for each language they handle.

More recent technologies like Dockers and Kubernetes have made some of the infrastructure easier. This then introduces new tech that needs to be secured.

That’s why when you’re faced with the need for a consistent security policy to be driven by your DevSecOps tech, there can be a battle with security tooling. The short answer is the development pipelines and configuration needs to be the driver. This contains the truth of what’s being built and means development can configure this once, as well as enable DevSecOps tools to work out how to run the necessary security testing.

HOW THE ULESKA PLATFORM WORKS THROUGH THE ISSUES

The Uleska Platform is set up to allow development and CI/CD configuration to drive security testing without adding additional work. Using a simple CLI (and APIs), the Uleska Platform can be updated in real-time with the codelines, images and boxes that are being used in different stages of the SDLC, so that it can then orchestrate the correct tooling to implement the security guardrails.

Ultimately, the Uleska Platform reports security information back to the CI/CD pipeline, as well as ticketing systems like Jira and Slack.

This not only saves time, since neither development nor security needs to onboard or configure the elements of the project, but it means issues being returned are real and not a legacy of an old component of the project.

To discover more about the challenges of automating DevSecOps and how to overcome them, check out our playbook.

LEARN MORE ABOUT THE CHALLENGES OF DEVSECOPS

One of the challenges with DevSecOps is incorporating many layers of security tasks into the fast-paced software development cycle. This slows down the pace and causes a variety of problems. Luckily, there are a variety of things you can do to overcome the challenges faced. In our playbook, we cover the top 10 challenges of automating DevSecOps, while also delivering actionable advice on how to overcome them.

The all-important triaging of security issues

Gary Robinson — Tue, 17 May 2022 09:25:23 +0000

Security tools can be noisy. In 20 years, we haven’t seen a single security tool return a set of issues that are 100% what needs to be worked on. Ultimately, there are a few main aspects to triaging lists of security issues to achieve better results from your tools.

In this post, we’re discussing the issues of triage software testing and how these problems can be solved.

Why certain issues may not need to be addressed
Security issue backlogs
How the Uleska Platform facilitates aspects of DevSecOps triaging

WHY CERTAIN SECURITY ISSUES MAY NOT NEED TO BE ADDRESSED

There are a few reasons why issues returned from a security tool may not need to be handled. These are:

1. False positives
For years, this has been one of the biggest complaints against security tools. Maybe they flag a port you want to be opened or they’re simply a result of the security tool engine logic thinking there’s an issue pattern.

2. The risks aren’t real
Sometimes a tool raises an issue that may be a problem in theory but just isn’t something that needs to be prioritised right now. We’ve all seen the flagging of some security header or a security issue in a library/framework that couldn’t be exploited on your system because you don’t use the relevant function in the library, or your security policy doesn’t require the use of the security header.

3. Duplicates
Now that our DevSecOps processes are running multiple tools, there’s a good chance we’ll see the same issue raised a few times. Different tools will focus on differing security checks, though will still likely have some overlap. We also see this often with different container or SCA security tools that use different vulnerability databases.

4. Duplicate occurrences
We typically see this when there’s some issue in the header or footer of a website. This often results in you getting the same issue raised for every page on your website, even though you’ll only need to apply one fix to solve it.

WHAT YOU SHOULD DO WITH YOUR SECURITY ISSUES BACKLOG

The concept of a ‘security backlog’ is changing with DevSecOps, due to the frequency of changes and testing. It’s then especially important for the DevSecOps process to determine the difference between this latest list of issues from the current change, and the previous list of security issues.

In the past, security tests would be handled manually, maybe every 6 or 12 months and would result in a long list of issues. This list would be triaged for false positives, leaving a list of challenges to work on.

This resulting list of issues would then be fixed and remain resolved for another 6-12 months. Any issues left would just be accepted risk.

The frequency of DevSecOps changes this narrative. There will likely always be a backlog of security issues to be worked on for every project and this would be reflected in the issues being returned by DevSecOps tools. Yet that backlog will constantly be changing from release to release. As an example, if our Tuesday 10am pipeline returned 50 issues - what does that mean?

Does it mean:

We already had 50 security issues and nothing has changed?
Before this pipeline scan, we’d fixed all issues and 50 brand new security bugs were introduced on Tuesday morning?
Before this pipeline scan, we had 60 issues and we’ve fixed 10?
Before this pipeline scan, we had 20 issues and introduced 30 new security bugs?
Before this pipeline scan we had 50 issues, but some have been fixed while new issues are introduced and the risk profile has changed?

If we assume we’re always going to have that backlog, then part of our task in DevSecOps is to easily determine the delta from the last security run - this represents the difference in issues (or risk) caused by the current code change being run through the pipeline. If we’ve introduced a few new issues, now is the time to flag, either by email/Slack/Jira or in CI/CD, since the new risk isn’t ‘real’ yet, because it hasn’t been deployed. This means the dev team can be aware and fix issues quickly since they’re in the code and the issue doesn’t become an exploitable risk by going live.

However, current security tools are not designed for this. Security tools are designed to run security engines, determine issues and provide a list of them back to you. Now we’re in a situation of running multiple tools and linking all of these lists for someone to work out what’s changed in our security backlog.

At the end of the day, it’s this ‘what’s changed?’ that’s important to security and the business. Many security policies state things such as “changes can’t go live with critical issues,” or “if the risk increases by 20%, or goes over X threshold, then it should be run past Y team.” This is the business end of the guardrail that DevSecOps provides.

So in the mindset of DevSecOps and in the timeframe of the pipeline, we need to:

Remove (or re-remove) false positives, duplicates, non-issues.
Compare the new set of ‘real’ issues against previous (using context).
Make a decision based on our security policy on how to handle any change.

This means DevSecOps technology should have the ability to perform this consolidated vulnerability management across multiple security tools. Keep in mind this includes all tools - commercial, open-source and all those custom tools and scripts every business relies upon.

You’ll also notice a positive cultural effect this will have between security and development. As mentioned previously, developers don’t want to handle long lists of issues in every release.

By automating security triaging, that conversation changes to only flagging ‘real’ issues during the pipeline - this is much more manageable and enables rather than distracts. If the security pipeline can be easily extended to allow devs to run them in feature and other branches, before merging to main, then this is an even better collaboration that empowers development and saves a lot of time for security teams.

HOW THE ULESKA PLATFORM FACILITATES ASPECTS OF DEVSECOPS TRIAGING

Firstly, for every security toolkit run, it collects all of the issues together into a single database and format. This list can then have false positives, duplicates and non-issues flagged via the UI or API, leaving only the real issues that affect the project.

Future runs of the same security tools will continue to return these invalid issues, but they’ll simply be marked as invalid issues again and kept out of reports and communications with other teams. This saves a lot of time for both security and development teams, whilst improving the quality of results for everyone.

For the second aspect of comparing lists of issues against previous runs, the Uleska Platform automatically stores all historical issue lists. When a new run is conducted, the lists of issues can be compared to instantly find new or fixed issues.

This can be quickly returned to the CI/CD pipeline for any decisions to be made and is stored in metrics so continual performance, statistics and improvements can be tracked. Trying to track this information across many tools would be a full-time job. That’s why we’ve automated it, so teams don’t waste time collecting and comparing lists of issues every release.

Instead, logic in the CI/CD pipeline can be applied to make decisions based on the consolidated information passed back by the Uleska Platform, without security resources being utilised.

The Challenge of running too many security tools in CI/CD

Gary Robinson — Wed, 11 May 2022 09:26:13 +0000

DevSecOps involves setting up many different automated security tools to cover all bases. It’s not uncommon for organisations to run tons of security tools due to the many types of AppSec scans that are needed to find all the types of vulnerabilities. This means a mix of commercial tools from different vendors, various open-source tools and many homegrown scripts and checks.
This ‘Tool Sprawl’ fragments the DevSecOps automation and holds it back. As the number of security tools grows and the DevSecOps processes become more complex, companies are realising the greater challenge is to make sense of all of the test results within a short period of time, like during the pipeline run.

Automating manual tasks in the process around automated security tools is very important for DevSecOps in CI/CD. The quality and effectiveness of the data from your DevSecOps processes and tech are going to be the difference between people using it and your continuous improvement, or teams simply bypassing it and it all being a waste of time.

Let’s go through the challenges in manual software testing and examine the issues when automating this DevSecOps process.

Choosing which tools to run in CI/CD
Running the various tooling in or out of CI/CD
Collect the test results from all the security tools into one place
Working out what’s changed in this software release
Triaging all your security issues
Prioritisation of your security issues
Communication with various teams
Security Metrics

CHOOSING WHICH TOOLS TO RUN IN CI/CD

We already know you’ll likely need at least 10+ security integrated tools to get enough security coverage for a single project. Chances are, your company will have different teams running different tech stacks. You may have different CI/CD pipelines designed for them. Trying to shoehorn a set of security tools as ‘one size fits all’ will not work for anyone. For example, running python security tools against a C# codeline will be a waste of time and offer a false sense of security.

Different types of tools are better at finding different types of vulnerabilities. Companies are combining DAST, SAST, SCA, IAST, Container, Cloud, and many more types of tools to find issues.

That’s why you’ll need to introduce lots more tooling to cater for the range of security checks varying teams will need. Your DevSecOps tech will not only need to handle those tools but also easily configure which are being used for a team or project. However, trying to configure these within the CI/CD pipeline logic is complicated and rigid.

The Uleska Platform allows you to pre-configure security ‘Toolkits’ that combine relevant security tools according to your projects’ tech stacks and dependencies. This is easily configurable without modifying the CI/CD logic and gives you more flexibility and control over the testing to be done, by simply adding two lines into your CI/CD workflows.

RUNNING THE VARIOUS TOOLING IN OR OUT OF CI/CD

Security tools come in all shapes and sizes and you’ll likely need logic for each and every one to get them to run. So where do you put this logic? Many teams initially try to place it in CI/CD, but as it grows in complexity, it tends to fit better outside the CI/CD platform so it can be updated and extended easily.

Kubernetes and dockers tend to suit the needed architecture of running these security tools well, but creating that setup will become a project in itself. This is why we have built the Uleska Platform architecture on top of Kubernetes and containers. Users can benefit from the sizing, queuing and monitoring of running security tests during the CI/CD builds in real-time - without having to get their hands dirty.

COLLECT TEST RESULTS FROM ALL THE SECURITY TOOLS INTO ONE PLACE

If you were to use three SAST tools in your pipeline, it’s likely that each of them is going to report issues in different ways. As there’s no industry standard on how to report security issues, they may do the following:

Report different fields
Report severity in different ways
Barely report much at all

From those three tools, one consolidated list needs to be retrieved. A call must be made on how to fix the issues at hand and what tools are required. This is where flexibility is vital, as you’ll need to add in more tools.

Essentially, this means implementing DevSecOps vulnerability management. Now your tooling extends to dynamic infrastructure, containers and other types. There’s likely no code fields with them, but now we’re handling port numbers, vulnerable HTTP requests and more.

For some companies, the task of bringing together the results from all of these tools is a full-time job, but one ideal for automation. That’s why the Uleska Platform does exactly that, with a single taxonomy for describing security issues that all results are mapped into.

For consumers of this information, including development and security teams, having a single and consistent pane of glass to flag security issues in near real-time during the CI/CD pipeline is invaluable.

WORKING OUT WHAT’S CHANGED IN THIS SOFTWARE RELEASE

Engineering and operations teams don’t have time to manage hundreds of issues across lots of security tools in every CI/CD run. DevSecOps for software security focuses on the ‘what changed?’ question. Consolidated sets of issues from the last change don’t need to be a War and Peace of every problem in the project. Remember, you’re building an efficient process to flag security issues.

Security tools are built to find every issue they can and report back. Yes, we want a baseline of all issues at the start of the project, but once we do that first triage, remove the false positives, duplicates and non-issues, we then want to move those known issues to our backlog and focus on anything new.

That means there are two things we want to know when security tools are applied to this run:

Have any NEW security issues come up?

New issues can come from code or config changes introducing new bugs or a security tool (or database) has been updated and found a new flaw in our existing containers and libraries.

Have any issues been fixed?

It sounds simple, but if a security tool has found an issue before, someone has applied a fix. Now the tool doesn’t find that issue so we can consider the fix assured and remove it from our lists.

With the right software, such as the Uleska Platform, historical security toolkit runs are stored and can be compared against the current run, so you can know instantly if new issues have been introduced.

TRIAGING ALL THE SECURITY ISSUES

How and where do you record false positives, duplicates and nonsense issues? Some commercial tools allow you to do this, while many don’t. The vast majority of open source and custom security tools can’t track this either.

Yet non-issues are the biggest problem in DevSecOps. Development teams don’t appreciate being given 100s of non-issues from security runs.

Market-leading platforms allow you to set false-positives and non-issues centrally, for all security tools and results it runs. These are sticky, meaning the next time you run the tools, all the non-issues are remembered and don’t show up in any reports, shielding development from these in communications.

Here at Uleska, we’re working on a number of new ways to make false-positive handling much more efficient, so security and development teams don’t need to waste time on this.

PRIORITISATION OF YOUR SECURITY ISSUES

If you’ve ever tried running many tools against the same target, you’ll find a few interesting things:

Not all tools will find all the same issues (you can use this to determine the effectiveness of the tools).
Multiple tools that do find the same issue will likely prioritise it differently.

This difference in prioritisation is not only frustrating, but it’s typically only based on the technical bug and completely ignores risk aspects of the project. It neglects the number of users, the sensitivity of data processed, the criticalness of the project to the business and so on.

Maybe low-risk issues can be passed through without intervention, but the highest top 10% of risks should go back to development for fixes before release. Software like the Uleska Platform provides this automatically within the CI/CD pipeline and further metrics - speeding up the decision making process.

COMMUNICATION WITH VARIOUS TEAMS

We’ve already examined how you can reduce the number of issues being flagged in each CI/CD run, however, there will still be an increase in the number of real issues that are flagged - DevSecOps runs at increasing speed and scale.

Requests to help describe the issue and communicating best practices or suggested fixes already in place can consume a lot of time, taking security teams away from other important tasks and slowing down development.

The Uleska Platform has built-in advisory functions that allow categories of custom remediations to be automatically incorporated into communications to development teams. This gives teams quick access to the advice, fixes, and education they need and allows security teams to scale their communication without consuming their time.

SECURITY METRICS

Even from a metrics point of view, the stakeholders in your company don’t want to have to go to lots of different security tools and make up the statistics. It’s inefficient and again becomes someone’s job, which prevents them from doing something more productive. It can take days to bring all the info together, meaning it’s already out of date.

Automating this during the CI/CD pipeline not only gives near real-time metrics on security, but since it’s being updated every release, you have a lot more granularity on the measurements. Seeing the difference between month one and month three, daily, is a lot better than measuring the difference once a quarter.

To discover more about the challenges of automating DevSecOps and how to overcome them, check out our playbook.

LEARN MORE ABOUT THE CHALLENGES OF DEVSECOPS

The problem with DevSecOps is incorporating many layers of security tasks into the fast-paced software development cycle. Thankfully, there are a variety of things you can do to overcome the challenges faced. In our playbook, we cover the top 10 challenges of automating DevSecOps, while also delivering actionable advice on how to overcome them.

Download it here!

Using DevSecOps to reduce issues raised

Gary Robinson — Tue, 26 Apr 2022 10:18:48 +0000

One of the biggest challenges when rolling out a DevSecOps process is the volume of issues it can bring to light.

From a development point of view, we don’t want the implementation of security in DevOps to give the dev team massive lists of vulnerabilities to check over on every build or release. We want to avoid anything that might cause unforeseen delays to keep everything on track - but we also want the application to be secure.

For that to happen smoothly, security needs to be snug in the process. So, how can we turn the hundreds of issues these DevSecOps tools are going to spit back at us every pipeline, into succinct and important issues that we can fix quickly whilst working on the code in tangent?

Brave the first issue triaging
Managing historical lists
Better understanding the risk of issues
Further reducing false positives

BRAVE THE FIRST ISSUE TRIAGING

Assuming you’re not starting the project from scratch, running a bunch of security tools is going to result in a decent sized initial set of issues. With so many hoops that devs already have to drop through, they’re likely to be ignored. Or worse, it blocks the build or release and lets non-important security issues you’re already aware of get in the way.

All the AI/ML in the world isn’t going to remove non-issues better than a manual step, so here we recommend getting stuck in. Treat this first run as a normal security test. Expect 100s of issues and be prepared to go through them and mark the false positives, duplicates and issues that just aren’t important right now.

To make this easier on future you, do this in a way that means these marked issues are programmatically recorded, regardless of the tools or scripts you're running. This means the next time you run the security tools through the DevSecOps process, they’re remembered and not flagged. Winner. By keeping them in an ‘invalid issue’ list, this means that instead of having a wealth of vulnerabilities reported, you’re only working with the small percentage of issues that are essential to resolve.

MANAGE HISTORICAL LISTS

Agile development is all about incremental changes. DevSecOps should be set up to work in the same way.

From above, we now know the (smaller) list of real issues currently existing in the project. Do we need to be alerted to those same issues in every pipeline run? No, instead what we’re interested in is any changes - has our change introduced any new issues? Has it fixed any issues we expected to be fixed?

By automatically managing and recording the lists of real issues existing in every pipeline DevSecOps run, we can then concentrate on the differences. For example, say last run we had 100 issues. This is fine, it’s our security backlog, we know about it and have plans to burn it down. Now, in our new pipeline run, we’ve identified 102.

This needs to be flagged up to make those new issues easily visible and actionable for all teams, regardless of the tools or script that flagged them. Enter DevSecOps issue tracking - matching previous issues consolidated from all the tools, with the current run, so differences can be easily flagged and handled. This is much better than trying to manually find the two new issues among the haystack of issues and tools.

BETTER UNDERSTANDING THE RISK OF ISSUES

Even with new issues being worked out and reported, the step where we need to look at those issues often breaks the automation workflow. Do we focus on every new vulnerability?

Ultimately, it depends. If they’re very low-risk issues that can wait until later, your team can prioritise big-ticket items instead. On the other hand, if these new issues are pressing and cause great risk for the app release, we really need to resolve them before going live.

Pioneering DevSecOps and security tools like Uleska, come with the ability to automatically determine the risk level of security issues. Going beyond CVSS, this takes all the laborious guesswork out of deciphering the major from the minor issues.

Calculating this risk inline with the CI/CD pipeline means that we can further reduce the issues we’re alerted to in real-time. You can decide on a certain threshold of issue risk that triggers an alert or holds the build.

This further reduces that abundance of issues being reported by the security tools, keeping only the very few that we actually care about. If these issues were to be raised weeks later when the feature is released, you’d be back at square one and go through the workflow of coding, testing and releasing again.

Getting alerted to these issues early on saves all teams valuable time. Time that can be put towards impactful app improvements.

This has been evidenced by Facebook, where a near 0% fix rate was seen when automated security checks were applied after release, compared to a 70% fix rate for the same automated security checks applied before release.

FURTHER REDUCING FALSE POSITIVES

When you delve further into security tools, there’s often a pattern in the issues raised - false positives.

What if there was a way you could setup your DevSecOps to implicitly identify these for what they are - potential false positives - and not flag them during the DevSecOps process? This would mean the relevant security personnel or developer could look at them later and raise an issue if they’re real.

Think of those common header issues that are flagged or that issue type from that tool you often ignore because it’s most likely a false positive. Pre-empting them as likely non-issues means they still get addressed, but don’t hold up the pace of the development cycles.

The Uleska Platform implements many of the above concepts to effectively reduce the scale of issues raised during DevSecOps. It ensures development teams are alerted to the important issues and other, low priority items are handled in the background. Dev cycles are frictionless, unless there’s a major issue.

The best part? This also helps combat the dreaded misalignment of dev and security teams, allowing them to work together since all the issues from each tool are captured and triaged in one, centralised place.

Taking hundreds of issues and automatically filtering them down also saves a lot of time, for everyone involved. With the added advantage that when issues are fixed, they’re automatically removed from the list when the DevSecOps tools stop reporting them.

Doing DevSecOps without constant CI/CD changes

Gary Robinson — Tue, 19 Apr 2022 11:27:18 +0000

Better collaboration between teams, faster time to market, improved overall productivity and enhanced customer satisfaction are just some of the benefits you can reap from successful DevSecOps.

However, it’s not just a matter of wrapping a few security tool APIs into your favourite CI tool and calling it a day. DevSecOps programs and tooling grow and mature, as new tools are added, teams come onboard and processes update. You don’t want to clog up and confuse your CI/CD pipelines with constant changes to accommodate DevSecOps.

There’s no ‘one-size-fits-all’ process for DevSecOps and we recognise every company will be at different stages. Here are some essential considerations to start with.

Make security part of the software development workflow
Automation, automation, automation
Finding your balance with automated security

MAKE SECURITY PART OF THE SOFTWARE DEVELOPMENT WORKFLOW

DevSecOps unites developers and security professionals, cultivating an environment of collaboration. But it’s hard to ignore that a certain level of friction has always existed.

Besides time, there are lots of things that naturally place pressure on the CI/CD pipeline when it comes to security:

Hooking in all the relevant security tools (APIs, docker, CLIs, etc)
Collecting, understanding and processing the results from all of these tools so you don’t just throw every vulnerability back to the development team
Prioritising which security issues to report on and which are not important
Communicating issues where they’re needed through channels like Slack, Jira, and others
Making any automated go/no-go decisions based on the security results. Are there big issues that need to be fixed before deployment?
Handling tool extensions and keeping new versions up to date
Recording security metrics to tell the full pipeline story

In one corner you have the development team and in the other, security. Both sometimes think what the other team does create nothing but work for each other. This perspective results in both teams working in silos, which defeats the main principle of DevSecOps.

Making security part of the workflow simply starts with a mindset change, which is easier said than done. DevOps teams spend their time improving and refining their pipelines based on the needs of the teams around them. Now, with DevSecOps, security teams are joining the party with requirements that aren’t as straightforward.

Security controls and tests need to be embedded early and often in the development lifecycle. With organisations potentially pushing new versions of code into production 60+ times per day, automated security is the answer.

If you believe increased security slows things down and creates a barrier to innovation, we’re here to dispel that. We understand your reluctance, but it’s just not the case when you have automation on your side paired with a platform that eases the job of adding DevSecOps to the CI/CD pipeline.

AUTOMATION, AUTOMATION, AUTOMATION

It’s not news to anybody that automation is a key characteristic in DevSecOps. For security to keep pace with code delivery in a CI/CD environment, automation of security is a given.

Organisations, where developers push code to production multiple times a day, will feel this more than anybody. Rapid and secure code delivery may sound like an oxymoron to most businesses. But DevSecOps aspires to change that.

Trying to run automated scans on your entire application source code each day can be time-consuming and hinder your ability to keep up with daily changes. So, before delving into a tool stack head first, tread carefully.

Teams responsible for application security can now use pioneering platforms to set the tool and test configuration as well as collect and consolidate reporting data to various other tools - all without changing the DevOps pipeline. This gives security maximum flexibility to make the changes they need to, without needing permissions for DevOps.

For added simplicity, we can use the Uleska Platform as an example for ease. The short API logic Uleska uses to run security testing is consistent for every project. This means regardless of the project logic or the CI/CD system being used, the same template can be used. Not only does it ease the job of adding DevSecOps to the CI/CD pipeline but it makes it quicker and easier for security changes to be made since they’re configured outside the main CI/CD logic.

FINDING YOUR BALANCE WITH AUTOMATED SECURITY

Doing DevSecOps right is a fine balance. If it’s approached as a simple automation task, it’s likely to result in clunky connections to an ever growing list of security tools, as well as large lists of security issues being thrown back at developers - and more delays to code being released. As if everybody didn’t already have enough on their plate?

DevSecOps processes in many companies are immature, but maturing. This means the tech, tools and processes are continually evolving as improvements are being made.

However, if this logic is based within the CI/CD pipeline, this results in continual requests to update the pipeline logic. Given there are already lots of pipeline requests and changes going on for other reasons, this means security has to compete for time, resources and capacity.

Although there’s a good case for saying the CI/CD pipeline isn’t the place to hold the logic or code to do DevSecOps, but if not there, where would it live? This is the reason the Uleska Platform has separated the setup and configuration of DevSecOps away from the core CI/CD pipeline, whilst still being driven by it.

At the heart of it all, 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.

Many of the tools required to insert security into agile DevOps are still emerging. As the methodology matures, you need a reliable platform that can scale with you, making it easy for you to adopt new tools, ways of working and to onboard new teams and applications.

OVERCOMING CHALLENGES TO UNIFY DEVOPS AND SECURITY

Eliminating manual security tasks by hooking end-to-end security automation into your CI/CD sounds like no easy feat - and you’re right. There are many challenges that may crop up on your journey to releasing faster, more secure code.

That’s why we’ve provided practical guidance for software security teams looking to save time when scanning and testing software - all without slowing down the delivery. Download your guide today to prepare for the security challenges your team might come up against.

How to fit DevSecOps into CI/CD Pipelines

Gary Robinson — Tue, 12 Apr 2022 09:31:41 +0000

Put simply, the goal of CI/CD pipelines is automation and a key goal of DevSecOps is to alert someone to a problem as early in the automated-delivery process as possible. It’s no wonder it’s a business priority, with many quickly realising DevSecOps is not just about plugging a few APIs into a CI/CD pipeline and calling it a success.

For those entangled in laboursome, traditional security measures, DevSecOps is a breath of fresh air. Security can no longer be secondary, here’s how to incorporate it into your pipeline.

How not to incorporate DevSecOps
Implementation of effective security guardrails
Embracing the agile approach

HOW NOT TO INCORPORATE DEVSECOPS

Failure is part of the tech transformation process. Only through trial and error can you keep innovating. It’s a key part of the journey to DevSecOps.

Don’t let your vision be limited by a silo. We’ve seen so many companies that have automated a portion of the security process in a pipeline realise that other valuable parts of the security process were missed and have caused a failure to make the automation effective.

There’s a number of tasks that would need to be performed in any security testing. Between the time a developer pushes their code to the time it goes live you need to make sure you’ve successfully:

Ran all the relevant security tools against the relevant assets
Collected all the issues together from each individual tool
Triaged the issues to understand any new risks introduced
Prioritised the new highlighted issues
Communicated the issues, stats and data back to the CI/CD process and to any other messaging systems

We’ve seen examples of DevSecOps pipelines that don’t make it as far as step two, by hooking in a number of security tool APIs. What this results in is a mass of issues sitting in a bunch of security tools that no-one is looking at.

If a security vulnerability comes to light and no-one is around to view it - does it even exist?

In effect, it doesn’t.

This is one of the reasons why the recent US Executive Order directly mentions the checking and remediation of security issues before release. See section 4 (e) (iv):

employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release;

Similarly, what can cause friction when shoehorning DevSecOps into your pipeline is completely automating vulnerability management, which comes only after security tools have been run manually by a separate security team.

With CI/CD pipelines running in minutes and the response time of overworked, understaffed, security teams being measured in weeks - you’ve guessed it, this tends to not work either.

To keep everything sweet between development and security teams, you need to implement effective security guardrails to provide low friction and low effort automation security checks.

IMPLEMENTATION OF EFFECTIVE SECURITY GUARDRAILS

During the CI/CD pipeline there are a few questions being asked of DevSecOps, which the process and tooling need to be able to answer.

Nearly every security tool out there is built with a different mindset from DevSecOps. They run, find a bunch of issues and return something convoluted back.

Okay, you’ve got some new issues being flagged up, what do you do with that?

Do you go to the security team for input?

No, because that’s a manual step and your aim here is to automate DevSecOps.

You need to develop solutions that don’t overwhelm CI/CD pipelines, yet allow flexibility for differing tech stack, security tools and environments. There’s a bunch of risk prioritization steps you can take to quickly and automatically determine if a new reported issue is a ‘must fix’ or a ‘who cares’.

*Yes, we already know there are already a few hundred issues in this project, we’ve accepted that and it’s in the backlog!
*
What we’re asking in DevSecOps is, have the latest changes caused any new and important security issues that we should report and worry about before going live?

To answer this, not only do you need to collect lots of info from typically lots of tools (in whatever format they return their results in), but you also need to work out what the difference is from the last run.

To facilitate the automation of this prioritisation, the Uleska Platform includes cyber risk modules that assign effective risk against every issue returned. This risk prioritisation logic is then configured outside of the CI/CD pipeline logic, meaning it can be changed seamlessly.

The CI/CD pipeline logic can have easy and consistent logic applied to make decisions based on the information returned. It’s just one way we can secure your software at speed and scale.

EMBRACING THE AGILE APPROACH

Traditional security professionals operate in a silo, with capacity limited by the number of security personnel inside it. Scaling manual processes is already an uphill battle so embracing the agile nature of DevSecOps has never sounded so good.

The framework focuses on the leverage of automation throughout the process. Leveraging DevSecOps practices and CI/CD pipelines enables organisations to respond to security and reliability events quickly and efficiently. Producing resilient and secure software on a predictable schedule and budget is every dev's dream.

Always remember, no standard implementation of a DevSecOps environment or a CI/CD pipeline exists that works for everyone.

Automation, armed with security, ensures that the best days of software delivery are ahead of us. Overall, your security arsenal enhances your credibility in the market and builds trust with consumers. With that in mind, there’s no better time to start preempting any challenges you might come up against.

PIPELINES AND PROBLEMS: EMPLOYING DEVSECOPS SUCCESSFULLY

Devising a framework that supports the ultimate goal of adopting DevSecOps practices mature enough to support fully automated CI/CD pipelines is no easy feat on your own.

How to Approach DevSecOps Security Automation

Gary Robinson — Tue, 05 Apr 2022 16:01:39 +0000

DevSecOps encourages security tasks to be wrapped and enabled with software development and operations tasks. The aim is to make them as seamless as possible while adding security value - and not more work.

Identifying vulnerabilities is essential but it’s also time-consuming and often costly. Staples like CI/CD tools have seen widespread adoption, serving as a wake-up call for development teams about the genuine need for secure code at speed. How do companies and teams answer that call?

Find your stride with security automation
Aim for a centralised security space
Give your team their valuable time back
Consider the longevity of your security solutions

FIND YOUR STRIDE WITH SECURITY AUTOMATION

Many companies are working to achieve automation that works and adds value - all without adding more tasks to the security personnel to run it.

When you move to security automation, you’ll find some security tasks that can be automated and others that are much harder to fit in. Architecture reviews and threat modelling can be challenging to automate and their heavily manual nature doesn’t allow for much labour saving.

Although a core tool for analysing security and identifying potential vulnerabilities, penetration testing has long suffered from the restraints of manual processes. Nobody wants to be shackled to this mundane yearly testing that doesn’t always give you the insights you need to move forward.

DevOps teams need the right software stack to fully realise DevSecOps or security by design. To be an effective addition, security tools must smoothly integrate with existing workflows.

This typically comes down to the following five categories of security checks or tools:

1. Static application security testing (SAST): Analysing an application from within, taking a closer look at the source code, byte code and binaries rife with typical security vulnerabilities.
2. Dynamic application security testing (DAST): Mostly used to detect security vulnerability for exposed HTTP and API interface of web-enabled applications.

Working similarly to IAST, RASP and similar tools, they all have their strengths when it comes to false positive rates, deployment and feedback.

3. Software composition analysis: An important offshoot of SAST which focuses on 3rd party components of code for known vulnerabilities and licensing issues.
4. Container analysis: These are your dockers, Kubernetes, etc. and they’re full of known holes. They can be used to harm you or just get flagged to give the dev team something to occupy themselves.
5. Infrastructure: The beloved cloud and on-premise solution; who doesn’t miss the days of needing to put a jumper on to go into the machine room?

Depending on what you’ll do with your DevSecOps program, you’ll likely need a combination of the above tools to give yourself adequate coverage. When you then examine the gaps you have in security testing and correlate against the types of issues you find in your processes, you can then add further security tools to your DevSecOps to increase failsafe.

AIM FOR A CENTRALISED SECURITY SPACE

Are you currently working with a range of tools with unique outputs and triggers in each environment? See how unproductive that sounds?

Often the data generated from siloed tools has entirely different outputs, files, terms and even how the data is formatted. This can be a nightmare to make sense of.

Making it easier to see what’s going on and where your current risk lies by consolidating security tools in a central platform is the way to go. This lowers the exposed vulnerabilities, ensuring it all runs smoothly and you can rely on visibility when developing.

GIVE YOUR TEAM THEIR VALUABLE TIME BACK

Everyone generally agrees that DevOps teams must adopt cybersecurity best practices, but everyone has different ideas of what that exactly means. With a well recognised skills gap in cybersecurity, security experts are in short supply. Often vastly outnumbered by developers too, they’re responsible for the security of code they played no part in writing.

Even when they can carry out the testing, they’re seen as a bottleneck that slows down the whole process.

Issues found manually by skilled penetration testers can be scripted up and added to your DevSecOps tech, facilitating all-important continuous improvements with time and each interaction.

We’ve seen this numerous times: an issue is found in one project, a script is created and run against other projects where the same issue exists. Think of the time saved in discovery and remediation tracking of that issue, not to mention the DevSecOps program has further reduced the risk for the company.

There are automated market-leading solutions that are happy just to get to work without any real need for maintenance or management. They can trigger tools to work at the right time depending on the outcome it finds - again, without any manual input needed.

This gives you and your team valuable time back to focus on what’s important.

CONSIDER THE LONGEVITY OF YOUR SECURITY SOLUTION

If we go back a few years, container and Kubernetes security were nowhere to be found in a standard security program, yet they’re now commonplace. Go back further and cloud security would have been a specialism to only a few. But like the business needs of today, the landscape has changed.

What hasn’t changed is security requirements. The automation opportunities, infrastructure and integrations available certainly have.

DevSecOps programs need flexibility built-in as standard to accommodate different types of security tools and allow security programs to mature without needing to be reinvented. There’s no use employing a system that doesn’t fill all the gaps.

Let the security processes and tech drive the security tooling used, rather than letting your security tool limitations affect your security processes. The first step is understanding what guardrails you’re looking for and work towards making that a success. Avoid setting yourself up for security failure by being aware of the challenges you’ll encounter.

OVERCOMING THE SECURITY AUTOMATION CHALLENGES YOU’LL FACE

It’s no surprise that when you strive for security automation, you’ll find some tasks can be automated and others that are harder to accomplish.

That’s why we’ve provided practical guidance for software security teams looking to save time when scanning and testing software - all without slowing delivery. Download your guide today to prepare for the security challenges your team might come up against.

Starting AppSec? Here's how you eliminate risk.

Gary Robinson — Fri, 04 Mar 2022 10:34:37 +0000

Building robust application security is a lot like building a house—you want it done thoroughly, without any missing parts. However, there is a difference between missing a lick of paint and missing an entire beam in the foundations of the building. One might look a little odd, the other could collapse the whole house.In the world of DevSecOps, calculating risk is a constant exercise. While you might be presented with thousands of issues every time you run a security check, not all of them are going to destroy everything you’ve built. It, therefore, becomes imperative to work out the level of risk posed by each raised issue, so you can act accordingly.

While the idea of sifting through thousands of potentially threatening issues might sound overwhelming, there are plenty of ways to easily navigate these kinds of findings. And awareness is the first step to success.

In this blog, we’ll discuss the benefits of eliminating risk (as far as possible!) when scaling your application security, as well as the tools to help you do it.

Here's the full guide to get you started

HOW TO AUTOMATE RISK MANAGEMENT

A good place to begin when managing levels of security risk is to work out how likely the threat is to cause long-lasting problems or significant cost if it were to happen.

To put your findings into perspective, at Uleska we give all detected threats an associated cost based on risk modelling. This way, users can easily visualise whether a threat is a high-priority that needs to be dealt with right away or something that could perhaps be fixed at a later date. For example, a risk showing up with a potential cost of £300 perhaps isn’t worth prioritising right now. On the other hand, you might find that a security issue that could easily result in a £6,000,000 fine. That one you’ll want to fix quickly.

With more and more high-profile security breaches making headlines as technology becomes more advanced and data more valuable, the pressure is on for companies to have a firm grasp of what could cause serious damage and what won’t.

RISK VERSUS VULNERABILITY

Similarly, an effective way to calculate risk is to work out the magnitude of the issue relating to where it is used in your business or project. We sometimes reference this as ‘risk versus vulnerabilities’.

A vulnerability is essentially static in terms of the technical problem, but the risk that a vulnerability represents to the different types of products can really differ. For example, many tools will flag an SQL injection—a common vulnerability—as a high-priority issue. But not all of these vulnerabilities will be high risk. Not all of them lead to important data breaches or even run the risk of being exploited.

To put this into perspective, a vulnerability relating to employee bank details is very different to, say, a vulnerability in the digital code that relates to your computer avatar. Both are risks, but only one is risky.

There are a number of risk models to help us think about the overall impact of vulnerabilities on our business. FAIR Institute is one of them. This particular tool lends itself to measuring risk values against technical flaws in software development.

We’ve implemented this framework inside our product here at Uleska. Whenever any of the tools we run bring back vulnerabilities, we automatically run through that algorithm to produce an impact and risk score. This helps understand across projects and vulnerabilities what the risks are and helps to issues, measure what’s happening and move forward.

WE KNOW THE RISK

Those working in the world of DevSecOps know that security issues are not created equal. But gone are the days when it was solely up to these teams to manually work out which are a cause for alarm, and which hardly require a shrug of the shoulders.

At Uleska, that’s what we’re here for. Calculating risk is our speciality, as is sourcing the tools to do it. Our platform makes starting your application security simple and seamless. And did we mention you can sign up for free?

Should you want a bit more information about finding the right tools to help you manage and eliminate risk, download our brand-new guide: The DevSecOps Toolkit, which provides comprehensive information on how to scale your application security, safely.

DevSecOps tool examples that will make your life easier

Gary Robinson — Thu, 03 Mar 2022 16:44:56 +0000

In the world of application security, every time you test with security tools (and you need lots of tools), it will throw up new issues that need to be managed and tracked—usually in a spreadsheet that takes time and accuracy to manage across all tools and projects. Typically, when you introduce new changes into your projects, it will then throw up newer issues which you then have to review against previous issues to check what level of priority they are, or whether they even need fixing at all.

In short: it’s a seriously arduous process.

COHERENT COMMUNICATION OF RESULTS

Alongside this core issue, there is also the wider issue of communicating your vulnerability assessment. That is to say, finding a coherent way to update, view and assess your findings with various teams and stakeholders, on projects with so many moving parts that are all updating so often.

Managers and exec teams are not going to want to trawl through a spreadsheet that houses thousands of granular findings around your tools. They also don’t want to be shown findings that are inaccurate or unnecessary, such as the same false positives, duplicates or non-issues over and over again.

You want a system that flags the important issues only, no matter what tools you use, every time you make a change. The good news is that such systems now exist and are here to make your life (and workload) a whole lot easier.

DEVSECOPS TOOLS & THEIR STAGE IN THE PIPELINE

So, without further ado, let’s have a look at some specific tools designed to alleviate your workload. There are hundreds of off-the-shelf tools to choose from, so we’ve grouped them based on particular stages in the pipeline—otherwise, as mentioned above, we’d be here for a while!

Continuous improvement / continuous development (CI/CD)

There are a multitude of CI/CD platforms out there, including GitHub Actions, AWS Pipelines, BitBucket Pipelines, CircleCI, GitLab, Jenkins, Harness and many more.

Taking Azure DevOps as an example, one of the main challenges here is the need to create lots of hooks in each pipeline to cover all the security tools. Using an Azure template to house the Uleska calls for your security toolkits makes it much easier to roll out security checks to all the projects. Azure DevOps can then show the findings from all the tools in one pipeline screen, making security decisions quicker and easier.

Find out more about CI/CD here.

Static Code Analysis (SAST) - Code or Build

There are over 60 commercial and open-source security code scanners. A good example is SonarQube—already used by many dev teams for its linting capabilities. Through the security check function, flaws can also be tracked for languages such as Java, Javascript and Python. These scans give feedback during the build/release process, spotting any new issues. We do see a great advantage in running multiple source code scanners, however, as they all find something different. Most teams run between 3-10 scanners just after the code has been built.

Find out more about SAST here.

Software Composition Analysis (SCA) - Code or Build

Late 2021 Software Composition Analysis tools have become all the rage due to the Log4Shell bug. And with so many libraries being included, checking for known issues against those versions is strongly needed these days.

OWASP Dependency-Check is a great open-source tool that scans your codeline build configuration and library files to match them against known issues. This may throw up a lot of issues - sometimes quite major ones - but you can quickly update the libraries to a patched version.

There’s plenty of commercial and open-source SCA tools available and they’ll differ in terms of their support for languages, or the vulnerability library they check against. If different tech stacks are used, we’d recommend running a bunch of these tools to see what fits best—the answer may be to run different tools for different tech stacks. This typically runs around the same time as static code analysis.

Container and Infrastructure as Code Security Testing - Build or Test

With so many teams moving to containers and infrastructure as code, you need to make sure these components don’t contain insecure configurations or known issues. Tools like the open-source Clair, which is also used by Amazon, can give you a picture of the security of your image layers, while the open-source Checkov tool from Bridgecrew scans your Kubernetes, Terraform, Cloudformation, and similar files for insecure patterns. Containers or IaC files are likely modified out-of-band to your application code changes, so these security checks will likely be added in a different place or pipeline, but still tied to the dashboard of the projects that use them.

Dynamic Application Security Testing (DAST) - Test

When the system has been deployed to staging, you can often find further issues by running dynamic security tests. Some types of security issues are better found when the system is running (instead of looking at the code).

BurpSuite has long been a favourite among security testers for its security scan against a live system. There are plenty of variables on setup, from the size of the system, to authentication, to coverage—but once set up, you can get consistent results by including dynamic testing alongside your automated functional testing.

Find out more about DAST here.

Cloud Security - Test or Release

There are hundreds of cloud security checks for all the major providers, and they are crucial to making sure the cloud setup is not vulnerable. Tools like Amazon Inspector for AWS give great coverage of both the network security and the CIS Benchmarks level of checks for the host operating systems. The only issue is the information is presented for all the systems under an account, which means work is needed to tie the issues found to individual projects—unless you have Uleska, of course!

PUTTING THIS TO PRACTICE

Should you want a bit more information about finding the right tools for your needs, download our brand-new guide: The DevSecOps Toolkit, which provides comprehensive information on how to scale your application security.