devopsy.kinsta.cloud

Tag: devsecops

Veritas Looks to Reduce Data Protection Costs

Veritas has extended the capabilities of the company’s NetBackup software as part of an effort to reduce the total cost of data protection.

Version 8.3 of NetBackup now includes Veritas Resiliency Platform (VRP), a disaster recovery tool, and CloudPoint, a tool for backing data up on a public cloud. All of these tools are part of what Veritas calls its Enterprise Data Services Platform (EDSP).

In addition, Veritas has integrated hardened NetBackup appliances and vendor-agnostic immutability for storage via its NetBackup OpenStorage Technology (OST) to help organizations recover from a ransomware attack more easily.

Veritas is also adding support for 2048-bit encryption and integration with third-party key management systems (EKMS) along with more flexible enhancements to the role-based access control (RBAC) it provides.

Other capabilities in this release of NetBackup include more granular recovery of virtual machines, the ability to orchestrated rehearsals to verify effectiveness of recovery procedures, and the ability to move data between cloud platforms.

Veritas has also extended discovery, backup, restore and automation at scale for Microsoft SQL, Oracle and Oracle Real Application Clusters (RAC) to simplify data protection processes spanning multiple classes of databases.

Finally, Veritas claims with this release, data protection via auto-discovery of resources and load balancing is now 25% faster and the discovery of VMware vCenter and vCloud platforms is 50% faster.

Doug Matthews, vice president of data protection and compliance for Veritas, said with the expansion of EDSP it’s now much more cost-effective to protect data residing on multiple platforms. In the wake of the economic downturn brought on by the COVID-19 pandemic, there’s much greater sensitivity to IT costs, he said.

At the same time, Matthews said Veritas is seeing DevOps teams become much more involved in automating data protection processes. Veritas has defined more than 600 application programming interfaces to enable DevOps teams to programmatically invoke its data protection software, he said.

Cybersecurity teams are also becoming more involved as backup and recovery becomes a core element of ransomware defense strategies, Matthews added. In an ideal world, anytime a ransomware attack occurs, a pristine copy of any impacted data would be readily available on another unaffected platform.

The convergence of data protection and cybersecurity has been a long time coming. Symantec once owned Veritas in the hopes of achieving that goal. Now Veritas is working with a much broader array of third-party partners to achieve that same goal, Matthews said. It may wind up being the rise of DevOps that finally forces that issue as data protection becomes one more IT task to be automated.

In the meantime, IT organizations may want to revisit their entire approach to data protection. Chances are good that most of them have multiple redundant data protection tools and services in place that have been acquired over time. Consolidating those functions ultimately not only reduces licensing costs, but it also creates an opportunity to automate a set of mundane tasks that all too often IT staff forget to perform consistently at a time that will prove crucial.

July 28, 2020
Upcoming Event: DevOps India Summit 2020
DevOps experts and business leaders from across the globe will come together to share their thoughts on DevSecOps, security and governance in DevOps during the third edition of DevOps India Summit (DOIS). Presented in a virtual environment, DOIS20 will take place on Sept. 9, at 9 a.m. IST.

At DOIS20, attendees will have the opportunity to interact with industry experts and learn how they have successfully implemented DevSecOps practices. The DevOps practitioners will share their experience and expertise, focusing on their company’s transformation to DevSecOps.

DOIS20 features an exceptional lineup of more than 35 DevOps thought leaders, including:
- Mark Miller, senior storyteller and DevOps advocate at Sonatype (keynote speaker)
- Piotr Lewandowski, senior staff site reliability engineer at Google Cloud (keynote speaker)
- Alan Shimel, founder and CEO at MediaOps (keynote speaker)
- Mirco Hering, global DevOps practice lead at Accenture (keynote speaker)
- Rosalind Radcliff, distinguished engineer and chief architect for DevOps at IBM
- Dr. Niladri Choudhuri, founder and CEO at Xellentro
- Hasan Yasar, technical director at Software Engineering Institute
- Sanjeev Sharma, co-founder and principal analyst at Accelerated Strategies Group and author of “The DevOps Adoption Playbook” and “DevOps For Dummies”
- Vandana Verma, Global Board of Directors at OWASP Foundation
- Ramesh Pasapula, assistant vice president at Wells Fargo
- Sailaja Vadlamudi, director of security and data privacy at SAP Labs and WiCSP founder
The online environment at DOIS20 features a lobby, an expo hall lined with booths full of downloadable resources and an auditorium where attendees can watch sessions from 8 a.m. to 6 p.m. IST. The expo hall will be open throughout the event, giving attendees the opportunity to chat with vendor sponsors and download information.

All registered attendees will have the chance to participate in contests and win incredible prizes, attend Q&A sessions with the speakers and will also receive a link to access the virtual summit on-demand.

For more information and to register, visit the DevOps India Summit 2020 website.
July 28, 2020
Snyk Tool Prioritizes Open Source Vulnerabilities

Snyk today announced it has enhanced the ability of its namesake vulnerability scanning tool by adding the ability to identify which open source vulnerabilities should be fixed first using a scoring tool that leverages data science and machine learning algorithms to analyze code.

In addition, DevOps teams can now take advantage of automated pull requests to fix those vulnerabilities.

Finally, DevOps teams also can define policies that require certain classes of vulnerabilities to be fixed whenever they are identified.

Aner Mazur, chief product officer for Snyk, said given the number of open source modules employed and the dependencies that exist between them, staying current on patches and updates has become a major challenge. The only way to achieve that goal is to rely more on tools that help automate that process, he said.

These days it’s easy for development teams to feel overwhelmed by patch requests to fix open source security vulnerabilities. The trouble is, not all those requests are of equal weight. Snyk provides tools that enable developers to understand which vulnerabilities are of the highest severity and how they might impact their code.

Armed with that insight, Mazur said, it then becomes possible to prioritize remediation tasks within the context of a DevSecOps process. Otherwise, developers will simply fix vulnerabilities regardless of relevance as time allows. Developers may remediate dozens of bugs only to discover that a critical flaw that had been left unaddressed led to a major compromise.

It’s also not uncommon for DevOps teams to fail to appreciate dependencies between open source code modules. When patches to code are applied in the wrong order, an application can break, resulting in DevOps teams having to start the whole process over. The prioritization tools provided by Snyk prevent that from occurring, Mazur said.

In the absence of any ability to prioritize vulnerabilities, developers eventually become inured to patch requests because they don’t know whether their patching efforts are making any real difference, he added.

Worse yet, all the time spent on patching low-level vulnerabilities reduces the amount of time developers have available to write new application code. In fact, one of the paradoxes of DevOps is as the number of applications deployed increases so too does the amount of time spent debugging them. Before too long, a DevOps team can find itself spending more time fixing existing code than developing new applications.

As DevOps teams become more dependent on open source code, they benefit from the collective security efforts of all the contributors to that project. The result is more secure code, as patches to remediate specific issues are made available. The challenge now is finding a way to automatically apply those updates in a way that doesn’t conspire to slow down the overall application development process. Achieving that goal requires visibility into what is now a multitude of open source projects that no DevOps team is ever going to be able to consistently achieve on its own.

July 22, 2020
How to Make DevSecOps a Reality

DevSecOps is an increasingly popular term; however, security vulnerabilities in software continue to proliferate. 2019 saw a surge in web application breaches shining a spotlight on the fact that DevSecOps remains elusive. The latest data from the Verizon Data Breach Investigations Report (DBIR) identified that web application vulnerabilities had doubled in the last year alone.

With the rapid pivot to all things digital in 2020, the pressure on software and applications continues to intensify. Security needs to be a fundamental part of software development in our digitally dependent world. This requires organizations to focus on more than the speed of delivery and turn their attention to the quality of software as they try to accelerate the pace of digital transformation.

Achieving DevSecOps

Organizations striving to achieve DevSecOps need to adopt the following steps to embed security throughout the entire software development life cycle (SDLC).

Make Security a Priority From Day One

Security can’t be a bolt-on at the end of the SDLC if your goal is to make DevSecOps a reality. The recent Zoom failures put security flaws in the spotlight and showcased the risks resulting from delivering innovative services without factoring in security. Every member of the team spanning product developers to technical architects to scrum specialists must consider security for it to be an intrinsic part of each stage of development.

Achieving this transformation to DevSecOps means rethinking how to determine success. Many organizations measure it solely in terms of velocity of time to market without evaluating software quality. Developers remain reticent to incorporate security and turn attention to the quality of code. As a result, software is released more rapidly but with scant regard for the quality, resulting in many applications not being ready for mass adoption.

One Size Doesn’t Fit All With Security

Don’t make the mistake of approaching security as a monolith. Instead, accept that it’s wide-ranging, incorporating multiple different areas spanning authentication to access control to confidentiality to integrity to non-repudiation, to name a few. Based on this broad scope, a single approach can’t hope to address all the different facets of security.

Teams need to rethink security and look at what it means to them and what is essential to their users. This could be keeping customers’ personal identifying information confidential and establishing the types of attacks that are most likely to occur. For example, if your product is inside a corporate file, then compromised credentials and password attacks are a significant risk while denial-of-service attacks are unlikely.

Every member of the team needs to understand security threats and techniques, so they have enough knowledge to deal with recurring issues. Threat models can include an employee unwittingly doing something wrong to trying to protect data from government-sponsored cybercrime professionals. Focusing your training on these areas will help address the vast majority of problems and ensure applications are secure. It’s vital to view security as a science rather that than an art.

Don’t Overcomplicate Security

Security is viewed by many as a problem that can only be solved by highly skilled and paid consultants who specialize solely in security. While there is an absolute need for these skills when reviewing architectures and carrying out audits, there is no requirement for this level of expertise when it comes to basic security checks, such as ensuring that the latest release hasn’t changed the authentication mechanism.

The vast majority of threat models are solved using standard static and dynamic analysis tools. Once this is accepted, you can resolve 90% of security issues through a combination of tools testers and developers. This enables security to infuse every part of the development life cycle and puts an end to the practice of being an afterthought.

Conclusion

Once organizations incorporate these three steps in implementing DevSecOps, they can ensure that achieving security becomes a core component of software delivery. Failure to do so will see that it remains an afterthought and security vulnerabilities will continue to grow.

July 20, 2020
RunSafe Allies With JFrog to Secure Applications

RunSafe Security, a provider of Alkemist tools that prevent memory exploits, has partnered with JFrog to create a plug-in for the Artifactory repository manager platform.

Alkemist employs a combination of runtime application self-protection (RASP) and moving target defense (MTD) methods to neutralize memory corruption exploits such involving, for example, a memory overflow.

Based on a research project for the Advanced Research Projects Agency of the Department of Defense (DARPA), the integration with Artifactory will make it easier to harden binaries and containers against memory corruption attacks before applications are deployed in a production environment, said RunSafe CEO Joe Saunders.

RASP describes a class of application security tools that detect attacks in real-time as an application is running. MTD refers to a strategy that relies on changing the attack surface regularly for applications to make it more difficult for cybercriminals to target them.

Cyberattacks that employ memory exploits attempt to either replace executables with malicious code or overwrite data in a way that changes application behavior. When aimed at operating systems, these attacks commandeer entire systems. They have also been used to launch self-replicating Worm attacks that both cripple systems and insert malware to steal data, corrupting files or installing a back door that enables remote access.

Saunders said the Alkemist plugin will enable developers to defend applications from these types of attacks without slowing down the pace of application development. Friction is removed from the DevOps process because as code moves through the DevOps workflow, Alkemist automatically hardens it to prevent memory exploits, he said.

With the growing popularity of containers, Saunders noted that as cybercriminals begin to target them the need to protect containerized applications from memory exploits using best DevSecOps processes will become even more pronounced than it is today.

While there is clearly a lot of interest in DevSecOps, most developers still don’t have access to the tools needed to better secure applications. As more cybersecurity plug-ins become available for repositories such as Artifactory, the easier it will become to embrace best DevSecOps practices.

JFrog, for its part, has been making a case for focusing DevOps teams on managing binaries rather than source code. The alliance with RunSafe extends that strategy into the realm of application security.

It may be a while before DevSecOps practices are widely employed. However, increasingly the issue is becoming less about the tools that might be available. Rather, the cultural challenges associated with implementing cybersecurity gates within a DevOps pipeline is now the major challenge. DevOps teams will need to reconstruct existing DevOps workflows to incorporate cybersecurity gates before an application is deployed. Once that’s accomplished, monitoring applications for anomalies will then need to be incorporated into observability platforms.

It’s not clear what role cybersecurity professionals will play in this new world of DevSecOps. The one thing that everyone can agree on, however, is the less involved cybersecurity professionals are in the application development and deployment process, the easier it should become to deploy applications that are truly secure.

July 16, 2020
Traceable Secures Apps Using Distributed Tracing

Traceable this week announced it is making available under an early access program a namesake platform that combines distributed tracing and machine learning algorithms to better secure applications.

Fresh of raising $20 million in funding, Traceable CEO Jyoti Bansal said the goal is to leverage distributed traces generated via open source Hypertrace agent software to capture streaming data to which machine learning algorithms can be applied to better secure microservices.

Bansal, who is also the founder and former CEO of AppDynamics, said this approach leverages software engineering techniques and principles to address application security issues both before and after an application is deployed.

As part of this effort, Traceable has developed TraceAI, a machine learning engine that has been trained to identify application security issues.

Once those issues are discovered, developers will be able to apply policies to remediate vulnerabilities using Hypertrace agent software, he said.

In effect, Traceable is applying many of the principles of application performance management (APM) platforms to securing applications. However, rather than simply aggregating and analyzing data, Traceable has added a streaming engine to collect massive amounts of cybersecurity data in real-time that is analyzed by machine learning algorithms to determine, for example, when and how data might be exfiltrated via an application programming interface (API).

As the number of microservices that are deployed in enterprise IT environments increases, the number of API endpoints that can be compromised does as well. By adding open source Hypertrace agent software to microservices, Bansal said it becomes possible to leverage distributed tracing to better understand the context in which how business logic embedded within a microservice is being compromised. That context also serves to enable development teams to remediate that issue by either updating or replacing a microservice.

While the rise of best DevSecOps practices has increased collaboration among developers and cybersecurity teams, Bansal said application security remains largely a software engineering challenge. Application development teams need to find a way to instrument agents to address application security issues within their code instead of relying on overlays deployed by network engineers, he said.

Most cybersecurity professionals would nod their heads in agreement with that principle. However, it may take cybersecurity teams some time to get used to the idea that they might not need to be as involved with application security as they are today. In fact, the amount of time spent looking for the root cause of any vulnerability is likely to be substantially reduced.

In the meantime, it’s apparent a primordial soup of agent software, distributed traces, machine learning algorithms and streaming data engines is coming together in a way that will transform application security. It may be a little while longer before the catalyst that converts all those elements into a widely employed platform arrives. However, it appears it’s now more a question of when rather than if there will be a major advance in application security that could take DevSecOps processes to a much higher level.

July 15, 2020
How to Source Vulnerability Data for True DevSecOps

Open source comes with code vulnerabilities that must be considered in the DevOps process

The war between open source and “only proprietary code” is long over. Open source won the day by convincing the opposition of the benefits of joining the open source community. “Vulnerabilities in the Core,” a report published by the Linux Foundation and the Laboratory for Innovation Science at Harvard in early 2020, explained: “Open source has now become an integral component of the modern economy and is a fundamental building block of everyday technologies like smart phones, cars, the Internet of Things, and numerous pieces of critical infrastructure.”

Development teams have embraced open source for its inherent strengths: efficiency, speed, quality and innovation. As one Gartner report puts it, “In most modern DevOps development projects, the majority of code used in an application is made up of open source.”

But open source comes with code management responsibilities that DevOps teams need to consider. Open source has the same security risks that plague all software—bugs or other defects that could be exploited by hackers. While larger open source projects have communities that generally issue patches for vulnerabilities much more quickly than commercial vendors, thanks to thousands of “eyes” on the code, keeping open source software secure is not as simple as enabling auto-updates, as is done for much commercial software.

Unlike commercial vendors that automatically “push” patches out to users, open source operates on a “pull” model. As patches are made available, consumers of the open source component first need to be aware that the patch is out there and then “pull” it from a repository to accomplish the needed update.

The NVD and Its Timeliness Problem

Public sources such as the National Vulnerability Database (NVD) are a good first step for information on publicly disclosed vulnerabilities in open source software. However, you need to keep in mind that there can be significant lags in data reporting, scoring and actionability of the data in an NVD common vulnerabilities and exposures (CVE) entry, with some research reporting an average 27 days between the initial announcement and NVD publication. The format of NVD records also makes it difficult to determine which versions of any given open source component are affected by a vulnerability.

For example, the Linux vulnerability CVE-2016-5195, popularly known as Dirty Cow, was announced Oct. 19, 2016. Proof-of-concept code exploiting the vulnerability was available a full two weeks before the Nov. 10 listing for the CVE in the National Vulnerability Database. That’s two weeks in which anyone relying on the NVD would have been left in the cold.

The problem is more recently reflected in the findings of the 2020 Open Source Security and Risk Analysis (OSSRA) report, produced by the Synopsys Cybersecurity Research Center (CyRC). Four of the top 10 vulnerabilities found in the audited codebases did not have CVEs associated with them at the time of the report’s publication. The vulnerabilities without CVEs included high-severity flaws in jQuery and FileAPI. Those security issues can be fixed with updates of the respective open source components, as can the majority of vulnerabilities listed in the CyRC OSSRA report. But, to patch any of those CVE-less vulnerabilities, you first need to be aware of them.

The issues impacting the NVD’s ability to publicize security vulnerabilities make it unwise to rely solely on that organization for vulnerability information. While I’m not recommending abandoning the NVD, DevOps teams should look to a secondary source of information that will provide better notification of vulnerabilities affecting your codebase and, ideally, supplement notifications with technical details and upgrade and patch guidance.

Augmenting NVD Vulnerability Information

Many commercial software composition analysis (SCA) solutions can provide you with more timely, richer vulnerability data than the NVD alone, proactively finding issues and helping you fix them quickly when warranted. If you’re considering an SCA solution, you should ask your vendor what they offer in the form of security advisories and alerts.

For example, consider the Common Vulnerability Scoring System (CVSS), an industry standard for assessing the severity of a vulnerability. The CVSS score (v2 and v3) provides an overall base score that takes both exploitability and impact into account.

A robust SCA solution will provide a temporal score in addition to the CVSS base, exploitability and impact scores. Temporal scores take into account metrics that change over time owing to events that are external to the vulnerability. Remediation levels (“Is there an official fix available?”) and report confidence (“Is the report confirmed?”) can help temper the overall CVSS score to an appropriate level of risk.

Similarly, an SCA solution should offer key Common Weakness Enumeration (CWE) classifications—a list of software or hardware weaknesses that have security ramifications—for all vulnerabilities, providing insight into the type of weakness being exposed. A CWE classification tells developers which type of weakness leads to the vulnerability in question.

Information such as this can help you understand what you’re dealing with and aids in assessing the severity of the vulnerability for mitigation purposes. For example, a development team may prioritize a SQL injection differently than a buffer overflow or denial of service.

July 14, 2020
ShiftLeft Brings Security Workflows to DevOps Processes

ShiftLeft has updated its NextGen Static Analysis (NG SAST) tool to include workflows that are purpose-built for developers.

Company CEO Manish Gupta said the security workflows are designed to make it easier for DevOps teams to incorporate them within their application development and deployment processes. In fact, a survey of more than 165 developers, application security and DevOps professionals conducted by ShiftLeft finds 89% of respondents said the current disconnect between developers and cybersecurity teams is the biggest inhibitor of productivity.

The issue with rival static analysis tools is they were not designed from the ground up to incorporated into a DevOps process, said Gupta. As a result, he noted, security workflows are managed around application development processes rather than being incorporated within them.

The survey finds that most IT teams are performing security scans too late in the software development life cycle (90%) and when they do discover an issue they often lack any remediation guidance (88%).

Most existing cybersecurity processes can’t keep pace with the rate at which applications are being deployed. The survey finds nearly 70% of software development organizations are releasing multiple times per month or more, with 18% releasing at least daily.

Gupta said NG SAST overcomes that issue by automating code analysis during every pull/merge request. That approach enables developers to address security issues much the same way they do any other bug. Rather than having to wait on a report from an application security team, developers can remediate a security issue from within their development environment log before it ever shows up in a report, he said.

Productivity and application quality improves because vulnerabilities get fixed faster while the code at issues is still uppermost in the mind of the developer, Gupta said.

DevOps teams can also create build rules that accept or deny merges based on how many security vulnerabilities there are, he added. That capability prevents security flaws from become too deeply embedded within the build process before they can be more easily remediated.

Gupta said security scans are also run locally where applications are deployed, which means source code never has to leave the organization. That approach also eliminates the need for network and firewall architecture updates to access an external scanning service. It also reduces bottlenecks inside organizations that might need to do as many as 20 scans per hour, he noted.

Overall, Gupta said it’s not uncommon to see developer productivity increase by a factor of 40 because ShiftLeft NG SAST enables scans to be run instantly. The days when developers took a coffee break while waiting for a security scan to run are now over, he said.

Of course, the level of productivity gain for development teams that might be gained by embedding static analysis within the application development process will vary widely. However, given the fact that developers outnumber cybersecurity professionals by several orders of magnitude, it’s also readily apparent dedicated application security teams can’t keep up. Unless organizations give developers the security tools they need, any ambitions an organization may have about implementing best DevSecOps processes will remain largely a pipe dream.

July 6, 2020
Snyk Report Finds Decline in Open Source Vulnerabilities

Snyk, a provider of tools for discovering and remediating vulnerabilities in open source code, today published a report that finds the number of new vulnerabilities discovered in open source software packages has declined 20% on a year-over-year basis. However, the bulk of the vulnerabilities being discovered are considered to be high severity, the report finds.

Alyssa Miller, application security advocate for Snyk, said the decline represents a significant improvement as developers become more conscious of cybersecurity issues. As long as humans write code there will always be security issues; however, Miller said the latest report suggests improvements in open source security are likely to continue as more developers embed vulnerability scanning tools within their application development tools.

Those tools enable developers to discover vulnerabilities in their code long before they ever find their way into a production environment, she noted.

The Snyk report is based on a survey of 500 developers, security practitioners and IT operations staff and scans run by Snyk on open source software packages. It finds the top vulnerability currently impacting scanned projects is prototype pollution, which results in objects in JavaScript applications being modified, was found in nearly 27% of all the projects Snyk surveyed.

Better-known vulnerabilities, such as cross-site scripting attacks, are still being reported in high numbers, but Snyk reported the number of projects actually being impacted by this class of vulnerabilities is fairly low. These threats appear to be getting caught and remediated much earlier than many lesser-known vulnerabilities, said Miller.

Want to learn more? Tune in Tuesday, June 30, at 11 a.m. Eastern for The State of Open Source Security in DevSecOps Pipelines: A Panel Discussion, a devopsy.kinsta.cloud webinar hosted by Snyk

The report notes the bulk of the vulnerabilities discovered continue to involve indirect dependencies (70%) within packages built using tools such as Node Package Manager (86%), Ruby (81%) and Java (74%). The survey also finds 60% of organizations do not fully inventory the dependency trees in their software.

Despite the progress being made, Miller said it’s clear much work needs to be done. For example, the survey finds more than 30% do not review Kubernetes manifests for insecure configurations. Requirements for security-related resource controls in Kubernetes are also not widely implemented, according to the survey. Many container images labeled as final contain large numbers of known vulnerabilities—the 14.3 Node image had 642 known vulnerabilities, for example.

In addition, 44% of the participants indicated that they are currently using Kubernetes to orchestrate their containers. Many respondents who said they use Kubernetes also employ Helm to package applications (40%). According to the report, 68% of stable Helm Charts contain an image with a high severity vulnerability.

Ironically, Miller noted many of the same vulnerability issues that have derailed many “golden image” initiatives in the past decade appear to be manifesting themselves again in the age of containers.

Finally, the survey finds 57% of respondents have implemented static code analysis tools (SAST), followed by employing security test cases during quality assurance (28%); dynamic application security testing (DAST) (20%); software composition analysis (19%); and threat modeling (19%).

Despite that relatively low reliance on security tools in the development process, it’s clear progress is being made as DevOps teams and cybersecurity teams collaborate more closely. As more security tools are incorporated into the DevOps pipeline, application security should begin to improve at even faster rates.

June 25, 2020
SaltStack Looks to Automate DevSecOps Processes

SaltStack announced today it has integrated its automation framework with a variety of third-party security platforms to further the adoption of best DevSecOps processes.

Mehul Revankar, director of product management for SaltStack, said version 6.3 of SaltStack Enterprise provides integration with offerings from Splunk, Tenable, Qualys, Rapid7 and Kenna Security. Data generated from vulnerability scans conducted using tools from Tenable, Qualys and Rapid7 can be directly imported into SaltStack Enterprise to inform automated DevSecOps processes, while integration with Kenna Security makes it easier to automate and prioritize vulnerability remediation based on the level of risk.

Revankar said that latter capability is crucial because remediation efforts should not be prioritized based on the severity of a vulnerability alone. For example, a vulnerability may be discovered in an application that sits behind a firewall, but if that application doesn’t provide access to the web an organization may decide to not patch that vulnerability immediately regardless of its severity because the risk of a breach is still relatively low, he said.

These capabilities will enable SaltStack Enterprise to serve as a foundation for providing security orchestration, automation and response (SOAR) capabilities within the context of a DevSecOps process by making it easier to incorporate cybersecurity within the context of a larger playbook for automating the management of IT, he added.

Most of those playbooks will be developed by DevOps teams in collaboration with cybersecurity professionals, noted Revankar.

In addition to improving DevSecOps processes, SaltStack hopes to make it easier for external applications such as Splunk and Datadog to consume data generated by its framework by providing compatibility with Prometheus, an open source IT monitoring tool developed under the auspices of the Cloud Native Computing Foundation (CNCF). A SaltStack Enterprise Splunk add-on tool has been added to the Splunkbase repository.

SaltStack is also making available a performance and health dashboard to enable DevOps teams to track 25 SaltStack Enterprise metrics that are surfaced using the Prometheus data format.

The open source Salt framework on which SaltStack Enterprise is based has emerged as a popular option for automating IT processes. Because it is based on Python, the barrier to adoption for Salt in terms of programming expertise is comparatively low to other programming languages. As such, more IT operations teams have been inclined to learn Python to leverage Salt to automate processes.

Like most vendors that have adopted open source business model, SaltStack extends the capabilities of Salt via an enterprise edition that it both extends and provides commercial support.

Interest in IT automation is on the rise as organizations of all sizes look to maximize what limited cybersecurity resources they have and cut costs. IT automation in the form of SOAR presents an opportunity to consistently apply cybersecurity policies more broadly without having to increase the size of the IT organization.

The challenge, of course, is having the expertise required to build a playbook. In the case of open source frameworks, many of those playbooks are shared among the members of a community such as Salt. Regardless of how those playbooks are acquired, it’s clear that as IT becomes increasingly more complex most IT organizations are not going to be to do without them.

June 25, 2020