Akamai Technologies, Inc. this week launched a service that consolidates the process of securing both web applications and application programming interfaces (APIs).
Amol Mathur, vice president of product management and strategy for Akamai, said with the launch of App & API Protector the managed security services provider is making it easier for IT teams to embrace DevSecOps best practices via a converged web application and API (WAAP) service rather than using separate tools and services to secure them individually.
The service is also designed to continuously discover API requests that are then automatically inspected for malicious code. Optional API security controls can be enforced based on policies defined by internal IT teams.
In addition, the company provides access to a multidimensional threat scoring model, dubbed Adaptive, that combines data collected by Akamai with data and metadata from each web and API request to help organizations better understand which threats require immediate attention. Security events are also continuously analyzed using machine learning algorithms to deliver highly accurate policy-by-policy tuning recommendations that can be implemented via a single click.
Akamai security researchers also make use of machine learning and data mining techniques to continuously analyze over 303TB of daily attack data that is used to automatically update protections. Alternatively, organizations can opt to manually evaluate that data themselves to minimize any unexpected impacts those updates might have on their applications.
Other capabilities include built-in bot mitigation tools that are informed by a directory of more than 1,500 known bots, integrations with the Akamai command-line interface (CLI), Terraform or scripts used to drive automated pipelines spanning a continuous integration/continuous delivery (CI/CD) platform.
A recent report published by Akamai found that between January 2020 and June 2021 there were more than 11 billion total attempted attacks made over an 18-month period. The most common attack vector was SQL injection (SQLi) at 6 billion attacks, followed by local file inclusion (LFI) with 3.3 billion attacks and cross-site scripting (XSS) with 1.019 billion attacks.
The report also found credential stuffing attacks reached more than one billion attacks and peaked between January 2021 and May 2021. Distributed denial-of-service (DDoS) attacks reached a peak of 90 in January of 2021.
Akamai has been making a case for outsourcing the management of web application and API security via the content delivery network (CDN) it created. Its CDN provides a layer of isolation between web-facing applications and the rest of the enterprise. The challenge organizations now routinely face is that, as they move to deploy cloud-native applications based on microservices, responsibility for security has become more decentralized. The security services provided by Akamai create an opportunity to better manage application security via a single pane of glass at a time when there is more focus than ever on securing software supply chains, said Mathur.
It’s not clear to what degree organizations are going to rely more on managed security services as part of a larger effort to embrace DevSecOps best practices. However, at a time when application security expertise is hard to come by, it’s becoming apparent that, in many instances, relying on an external service provider to secure application environments is the simplest way to quickly improve the overall security posture of any organization.
Your web application firewall (WAF) is humming at the edges of your network, faithfully blocking malicious attacks before they can do any harm.
Better yet, it’s a next-generation WAF (NG-WAF). It consists of signatures, rules, and a sprinkle of machine learning to protect your applications (and user data) from harm. You’ve got it covered, correct?
Yeah, right.
You’re a security expert. You don’t take anything at face value. How do you know for sure your applications are protected?
And what if you have cloud-native applications — microservices, HTTP requests flying around, multiple touchpoints for each user request? Can an NG-WAF protect all of these apps from external and internal attacks?
We’ve discovered the answer. Let’s take a look at what NG-WAFs do well, what they struggle with, and whether a solution makes up for their gaps.
The Challenge of Traditional Web Application Firewalls
A “web application firewall (WAF)” is an application firewall for HTTP applications. It applies a set of rules to an HTTP conversation. Generally, these rules cover common attacks such as Cross-site Scripting (XSS) and SQL Injection.
Modern applications are more transparent than traditional web applications. Focusing on speed and agility of development — Continuous-Integration, Continuous-Delivery (CICD), and DevOps replacing the waterfall development model — developers tend to use open-source projects to save development time and cost.
This transparency, ease of access, and incredible detail in documentation make the modern applications attractive targets. The frequent changes in applications make it almost impossible to detect and secure every vulnerability.
WAFs have added new features over the years, but the backbone of their detection still lies in their signatures or rules. The question is: have WAFs indeed adapted to the needs of cloud-native applications?
Applications have evolved from massive monoliths to microservices and distributed architectures. They now live virtually in any combination of public, private, or hybrid cloud. The new challenges and threats brought on by distributed architectures have given rise to the NG-WAFs.
Network firewalls underwent a similar transition, where the Next-Generation Firewalls (NGFWs) introduced a new perspective of looking at firewall traffic with deep packet inspection and attack-centric detection models.
The next generation WAFs have been frequently defined with three principal characteristics:
Detection is based on the application and the attacker’s behavior.
Going beyond signatures to identify anomalies and fundamental attacker actions.
Cloud-native deployment supporting various cloud platforms, APIs, and microservices architecture
What NG-WAFs Solve
NG-WAFs propose to solve the new problems introduced by changing application architectures.
How well have they done? Let’s start by reviewing what NG-WAFs do well.
Increased Cost to Attackers
Attackers have a distinct advantage — they don’t play by the rules.
We live in an age when you can connect almost any device in your home to the internet. Unfortunately, many IoT devices don’t take security measures, which means attackers are salivating at the opportunity.
Malicious actors try to mask their origin and evade detection using an army of “bots.” Yes, they’re attacking you with DVRs, cameras, and lightbulbs.
NG-WAFs take a fresh approach of correlating such behavior to detect the attackers and block them, thus increasing the cost for attackers and partly deter the script kiddies.
Layered Protection: The In-depth Defense
Defense in Depth increases system security by using a multi-layered approach with intentional redundancies. It’s commonly referred to as the “castle approach” because it mirrors a medieval castle’s layered protection. If one layer fails, another is waiting to take its place.
NG-WAFs have evolved to protect at multiple levels, including the traditional perimeter and the newer approach of embedding alongside the applications. These layers make an attacker’s job much more difficult and expensive.
Machine Learning and Behavioral Analytics with Automated Policy Learning
NG-WAFs aggregate detection from multiple applications to understand attackers from a broader perspective to contextually score them. Using machine learning and behavior analytics on the aggregated data, NG-WAFs automatically disable signatures that would trigger false positives and update the application policies accordingly.
Virtual patching
You ideally want to identify and fix every vulnerability found in your code. But real-world business situations dictate that not all vulnerabilities will be fixed quickly or at all.
A few NG-WAFs support virtual patching to prevent attackers from exploiting critical vulnerabilities until an official fix is available.
Cloud-native Support
NG-WAFs now support deployment in a public, private, or hybrid cloud. The NG-WAFs automatically integrate with a containerized approach to scale security natively and elastically. They distribute nodes all over the world to maximize coverage without increasing latency.
What NG-WAFs Have Failed to Solve
NG-WAFs have made strides in securing applications. They’ve used defense-in-depth to make successful attacks increasingly tricky to pull off.
They’ve incorporated new architectures and virtual patching to match the pace and style of current app development. But they haven’t solved every problem.
Let’s look now at what NG-WAFs are missing that may open up holes in your security.
Motivated Attackers Can Bypass NG-WAFs
WAFs introduce obstacles for hackers and penetration testers by making vulnerability finding and exploitation more resource-intensive. However, an experienced hacker or a researcher with enough motivation would probably be able to find ways to bypass it.
When the application use case becomes complex, it may demand disabling many defenses that produce a higher false positive rate. The more complex a web application is, the bigger its attack surface, and the easier it is to find a bypass for it.
NG-WAFs Are Vulnerable to Use Case Exploitation
The same application deployed in different contexts exhibits different behavior. Requests that are harmful for one application may be perfectly normal for the other as user behavior varies for each case.
NG-WAFs do not have a complete picture of application usage — they cannot detect the business use case. The attack patterns stay hidden within regular traffic and nested protocols. Eventually, the attacker can tune himself to the business traffic and bypass the NG-WAFs resulting in a window of vulnerability and delay in breach detection. Straightforward implementations for detecting such use case exploitation often result in a high rate of false positives and false negatives. Further, customers rarely use all of the available features and rules in modern NG-WAFs.
Machine Learning and Behavioral Analysis Are Limited to Perimeter Defense
NG-WAFs have evolved from WAFs and base themselves on a “perimeter defense” model — it guards only against malicious traffic originating outside the network. However, this model fails if an attack comes from within – a common occurrence given the wide variety of ways users can connect to an internal network.
The new “stay at home” normal and increased risk of insider threats has led enterprises to adopt the Zero Trust model. It is essential to monitor the external traffic along with the internal flow and state of the applications.
Missing Runtime Protection
Malicious hackers are attacking all the application stack tiers, be it web, memory, or database. By design, NG-WAFs are limited at the edge of the application module and cannot protect the application at runtime. With this knowledge, the attacker could also circumvent the virtual patch defenses once the vulnerability is known to them by altering their attack method or mingling with the business traffic.
Monitoring blind spots
Monolithic frameworks base the visibility into the application on logging frameworks. Want to know what’s happening? Only one directory to check.
Modern applications built on microservices and serverless introduce advantages to application development, but there’s also the cost of reduced visibility. You can monitor each service individually, but one can quickly lose sight of the global system behavior.
A single request to the modern application can create a chain of calls behind the scenes. What appears simple can sometimes be incredibly complicated. For example, take a look at what happens inside Netflix when you hit play during your latest binge.
This call chain generates a massive amount of data along its flow path. External applications have trouble ingesting it all. Instead of solving this problem, most NG-WAFs limit the amount of data they can capture and process, introducing blind-spots the attackers can leverage to bypass them.
How to Protect Cloud-Native Applications
Cloud-native microservice architectures introduce drastic benefits but are also challenging to defend. While NG-WAFs have made some strides, they still fall short in several crucial areas. To comprehensively protect your cloud-native apps you should look for a solution that seamlessly provides both security observability and intelligent threat detection. Look for solutions that offer:
end to end distributed tracing and visibility, increasing the accuracy and depth of attack detection without extra overhead
features that establish baselines for user behavior, API logic, and data flow to identify anomalies
the ability to block business use case abuses, insider attacks, and threat actors, even in distributed systems
visibility that provides a complete picture of how data (especially sensitive business and personal data) moves throughout your application so you can see problem areas before they become exploits
discovery and protection of the complete eco-system of your microservices
When it comes to website security, even an iota of prevention is really worth a large pool of measures to restore a website from its affected state. WordPress websites are most vulnerable to security attacks from sophisticated hackers as well as the bots that are capable of exploiting security vulnerabilities. These security vulnerabilities range from weak passwords, outdated themes and plugins, and poor-quality web hosting.
But, there are several time-tested measures that can prevent such security compromises and risks and keep a website performing and secure.
Make Use of Strong Passwords
Weak passwords often cause security risks for websites. You can prevent such risks by using strong passwords and for this, you can use tracking tools such as 1Password that can track all the passwords and prevent you from using the same password on all your internet accounts. The tool also prevents you from using easy and easily rememberable passwords. Thanks to the tool you can only use unmemorable, long, difficult passwords.
Using this tool you can easily test the strength of the existing passwords and can create passwords that are long, complex and not easy to guess. The tool helps you maintain all your web accounts with strong passwords.
Updating WordPress Core, Themes and Plugins
Most updates of the WordPress core, or the themes and plugins, come to mitigate the security loopholes and risks. This is why making updates once a month is far from enough. Whenever a vulnerability will surface, your non-updated website can be the first victim of the security risk. This is why one must update as soon as there is an available update. For all the plugins that don’t come with important features and functions, one can use a Shield WordPress Security plugin to auto-update.
Insist on WordPress Hardening
There are several WordPress hardening methods that can easily prevent hacking from taking place. Let’s have a quick look at these hardening methods.
Add extra allow/deny rules through your .htaccess file.
Keep login URLs restricted to specific IP range(s).
Safeguard your wp-config file.
Prevent image hotlinking and mobile directory browsing.
Do not use public WiFi or VPN to log in to the website.
Remove unused WordPress plugins and files.
Keep the server clean.
Prevent a WordPress Hack with a Website Firewall
A vast majority of WordPress websites are frequently hacked as they are more vulnerable to security risks than other CMS platforms. A common issue that security experts stumble upon often is that WordPress version update is often not possible, thanks to the incapabilities of plugins or themes. This is when a WordPress website can easily become vulnerable to hacks.
For such cases, enabling a WordPress firewall is strongly recommended to provide security patches for your website. A Web Application Firewall (WAF), when enabled, can take on such security risks. A WAF basically works like a pass for your website visitor traffic, and effectively filters out bad requests comprising hack attempts, exploits, DoS attacks and many more.
A WordPress firewall does the following things to strengthen WordPress security:
Prevents all future hacking attempts by detecting and thwarting all hacking methods and behaviors, thus keeping your WordPress website protected against malicious attacks.
The firewall provides a virtual security update for your WordPress website software, even when the website doesn’t have any new security updates.
A WordPress firewall also blocks brute force attacks or any unwanted visitors from accessing the wp-admin or wp-login page and makes use of brute force automation to detect your password.
It deals with Distributed Denial of Service (DDoS) attacks that basically try to overload a web server or the resources of an application with too many requests. By blocking DDoS attacks, a WAF ensures constant accessibility and performance of a WordPress website in all circumstances.
A WordPress firewall helps boost WordPress performance by storing website caches and keeping bounce rate lower. This also ensures optimum website engagement, business conversions and steady search engine ranking.
The cloud-based WordPress firewall solutions, besides preventing attacks, also boost WordPress website speed by using a Content Delivery Network (CDN).
Make Sure You Have an SSL Certificate Installed
This is a basic and very important security measure for most websites. It safeguards data by encrypting the data you and users use and transfer via a website. For example, when one submits a contact form or uses login in web pages, the data that is transferred remains encrypted. With SSL installed on a website, secure login can be ensured even while traveling. While some hosts and hosting plans provide this for free, with some you need to use a separate SSL plugin for the purpose.
Avail Better Web Hosting
Choosing good hosting companies can also be crucial for your WordPress security. Some hosting service providers such as WP Engine, Kinsta, Site Ground and a few others are great for WordPress security. These service providers take care of routine security scans and provide cleaning of hacked websites for free. Apart from performance, one should also consider security aspects for website hosting.
Taking Backup of Your Site
Though taking regular backups may not always be effective for preventing a WordPress hack, they can sometimes play a great role in disaster recovery. It is particularly useful in preventing a website database from damages due to malicious attacks.
Continuous Website Monitoring
Finally, continuous monitoring of websites can help greatly in tracking and mitigating security risks of all types. Setting Google Search Console alert is important concerning all issues on your website. Apart from that, you should monitor the error logs on your website through the cPanel File Manager or FTP (SFTP). You should also see the Raw Access Logs on the server to keep track of the users accessing website files on the site. You should also use a plugin called Shield WordPress Security plugin and use its Audit Trail feature to keep track of all the file changes and website accessibility issues.
Conclusion
All the above-mentioned ways are time tested as successful to prevent security attacks and keep security vulnerabilities at check. These measures, besides a meticulous choice of plugins and themes, can help a WordPress website perform well and remain secure.
Runtime application self-protection (RASP) has taken a fair bit of scrutiny over the last few years. Like many security technologies that pioneer new ways of tackling old problems, people inherently don’t like change. Several companies entered the space early and early adopters helped mature various RASP solutions on the market and the technology has advanced rapidly.
When applications began to be the favored target of bad guys, tons of companies started to reposition their perimeter security products closer to the application. Web application firewalls (WAFs) are similar to IPS for the network, so easy mind shift for most security practitioners. The problem is they require you to know your adversary. That’s like asking a security guard to keep out a single troublemaker, while letting in their associated gang of thugs.
As we saw recently with WebLogic, exploiting applications is a shell game. When one vulnerability is exposed and patched, another one, which shares the same modus operandi, comes out. When reports came out comparing the most recent WebLogic vulnerability to vulnerabilities found last year in CVE-2018-2628, CVE-2018-2893 and CVE-2017-10271, Oracle posted a blog explaining last year’s vulnerabilities had been patched. The problem was the underlying code mechanism that led to the above-mentioned CVEs (insecure deserialization) had not been fixed.
Deserialization is a perfect illustration of why RASP is the Chuck Norris of application security. Instead of applying a patch (which in the case of Oracle’s WebLogic, blacklisting the exploit method via a patch), RASP looks at the totality of the code before it executes and says, “If it looks like a duck and quacks like a duck, apply a roundhouse kick to the entire enumeration.”
It’s important for enterprises to protect their customers from insecure deserialization with RASP products. Further, it’s critical to consider learning and debunking some of the common misconceptions in the overall perception of runtime security:
Performance Impact
Evaluate an agent-based solution, which often makes app owners concerned it’ll impact the performance of their applications. When evaluating RASP providers, especially agent-based solutions, ask for agent size, performance benchmarks and certainly conduct your own performance testing during evaluation.
Writing Secure Code
With the DevOps movement, companies have ramped investments in training and programs around secure development practices. And while security is shifting left with this movement, programming still has a little bit of art infused, especially when developing applications that have been around for a long time and have seen variations in development resources. As is the case with WebLogic, application developers should create apps with security in mind, but they don’t have a crystal ball and exploits evolve just as applications do.
My Developers Will Become Lazy
Somewhere in these early days of RASP, the notion came about that RASP means you no longer need to remediate vulnerabilities in your application source code. Notably, the root cause of all vulnerabilities should be fixed as soon as possible. However, RASP can also function as an insurance policy allowing DevOps teams to better plan fixes and prevent derailing other projects focused on the business.
Why Do We Need RASP If We Have a WAF?
The WAF has become ubiquitous in most organizations and it is certainly valuable for organizations looking to take a defense-in-depth strategy. WAFs have become a significant strain on resources as they produce unmanageable amounts of false-positives that require constant tuning. In a recent survey by Ponemon, it takes most organizations 45 hours a week to address alerts and 16 hours per week creating or updating rule sets.
Hopefully, this article illustrates more color to today’s RASP. We’ve seen a lot of advancements in the early days of this technology and hopefully that will mean a lot less headlines.
If the only reason you have a web application firewall (WAF) is for compliance, you deserve better. It’s time to replace it with something that provides not only compliance, but real security value as well.
In the land of web application security, there are a few not-so-well-kept secrets, arguably none bigger than this: The WAF survived not by being excellent, but by being mandated.
The WAF is an antiquated technology that was created to help stem the rise of application security vulnerabilities, which had been overwhelming organizations with their frequency of discovery. Static and dynamic analysis tools dumped huge quantities of bugs onto development teams that had no possible way to fix so many code issues.
Meant as a stop gap measure to address this problem, the WAF made it possible to filter out rampant SQLi, command execution and XSS attacks that were threatening to consume all of the development and security team’s available resources. The idea behind the WAF was that the application bugs and security flaws would be triaged for now, and then eventually fixed in the code at the root of the problem.
At the time, a drop-in web application security filter seemed like a good idea. Sure, it sometimes led to blocking legitimate traffic, but such is life. It provided at least some level of protection at the application layer—a place where compliance regimes were desperate for solutions. Then PCI (Payment Card Industry) regulations got involved, and the whole landscape changed.
PCI requirement 6.6 states that you have to either have a WAF in place or do a thorough code review on every change to the application. Given the unappealing nature of the second option, most organizations read this as a mandate to get a WAF. In other words, people weren’t installing WAFs due to their security value—they just wanted to pass their mandatory PCI certification. It’s fair to say that PCI singlehandedly grew the WAF market from an interesting idea to the behemoth that it is today.
And the WAF continues to hang around, an outdated technology propped up by legalese rather than actual utility, providing a false sense of security without doing much to ensure it. If that isn’t enough for you to show your WAF the door, here are four more reasons why WAFs should be replaced.
The Minimum WAF Rules Approach is Broken
A common side effect of a WAF implementation is the blocking of legitimate traffic. In the application security business, we call these false positives. Don’t be fooled by this innocuous phrasing—what it means is that customers aren’t able to buy things they want, or upload their latest vacation photos or generally use the functionality of your applications. It’s the kind of experience that can quickly turn current customers into former customers.
To combat WAF false positives, most companies run the bare minimum number of rules to get by. This means that only the most obvious and most egregious attacks are caught, while everything else just sails right past the filter. Simple rules mean easy-to-bypass rules, leaving you with an ineffective WAF.
Learning Mode is Broken at Speed
One way that WAFs try to cut down on false positives and avoid breaking valid traffic is through a “learning mode.” In learning mode, the WAF learns what normal traffic looks like versus what malicious traffic looks like and protects accordingly. A lot can be said about how tough it is to get learning mode right, even under perfect conditions, but let’s skip to the real problem we see in production environments.
Learning mode takes time. WAFs that need to learn to recognize “normal behavior” require a certain amount of traffic review before they can actively block everything else. It may take a few hours to learn safe application traffic patterns.
When you move from waterfall to agile and DevOps, deployment speed gets faster and faster. The application code changes weekly, daily or even hourly. If you deploy using anything close to a modern cadence, putting the WAF in learning mode on every code change means you are always in learning mode. Essentially, any kind of learning mode, when applied to modern application development techniques, just can’t keep up with the pace of production.
Monitoring Mode Really Isn’t Compliance
The fact that WAFs have survived due to legal mandates rather than effectiveness isn’t the only open secret in the business. You also won’t be shocked to hear that most companies never put their WAF into active blocking mode. After all, blocking mode has high false positive rates and breaks your legitimate traffic, so it’s the way to go only if you’re hoping to break your application.
Instead, the WAF is run in monitoring mode, where it watches traffic and logs any event as an attack. When it’s time for audit, the WAF gets flipped on for a short bit, then back off again. In reality, of course, some auditors don’t even care if you have it in active blocking mode. Just having a WAF in place is good enough for them.
Running your WAF in monitoring mode is not an effective control. All it does is add a false sense of security and additional overhead to the security team to evaluate logged events. In this scenario, you’re spending money where it doesn’t need to be spent while adding close to zero defensive measures.
CDN-based WAFs Were for Convenience, not Effectiveness
The last not-so-fun thing about WAFs is their daily care and feeding. Your WAF adds complexity to your network, and having to dynamically scale it in the cloud is not exactly easy. Enter the content delivery network (CDN). Since most shops are already using a CDN to offload web application woes, why not add a WAF at the CDN layer? This meets compliance (yay!) and we don’t have to manage it (double yay!).
For many enterprises, this idea is the win-win that has allowed the WAF to persist even as its usefulness has been questioned. The problem with the CDN-based WAF, though, is that you end up running the WAF with a minimum set of rules again (see above or here), leaving the door open to all kinds of attacks. In fact, in my work at Signal Sciences, many customers use our web protection platform behind their CDN-based WAF and discover tons of real attacks that happily made it through the CDN.
If compliance is your main goal, go ahead and use a CDN-based WAF. If you want real defense, look elsewhere.
Achieve Compliance and Real Security at Speed
If this article sounds a little too familiar—if all you’re getting from your WAF is compliance—then it’s time to replace it. There are new options for adding defense at the web application layer and achieving compliance at the same time—for example, using runtime application self-protection (RASP) or next-gen WAF to provide application-aware defensive coverage. This means that, instead of just checking a box for PCI, you can be actively defending against the OWASP Top 10, account takeovers, instrument business logic and fight off bots, all without interfering with legitimate customer activity.
Don’t settle for compliance alone. You can achieve both compliance and real protection—and that’s what your business and your customers deserve.
At the same time, Barracuda Networks revealed that it has integrated all of it firewall offerings with the Microsoft Operations Management Services running on the Microsoft Azure Cloud. Finally, Barracuda Networks announced it is now including a software-defined wide area network (SD-WAN) capability with the Barracuda NextGen Firewall platform.
Tim Jefferson, vice president of cloud for Barracuda Networks, says the REST API the company is exposing in its WAF enables IT organizations to better manage security within the context of larger DevOps environment. As part of that effort, Jefferson says, Barracuda Networks also plans to integrate its WAF offering with other IT automation frameworks.
Jefferson says many IT organizations are discovering that public clouds are more secure than on-premises environments because of the level of security and instrumentation that cloud service providers now routinely include. For example, cloud service providers make it easier to track unusual API calls that might indicate an IT security breach or even an attack in progress. Those capabilities, says Jefferson, make it easier for vendors such as Barracuda Networks to provide more visibility into what’s occurring in a public cloud than what’s generally feasible on-premises.
However, each cloud service provider has its own unique network stack that requires security tools to be optimized for each platform, says Jefferson. Because of that issue, most IT organizations have not had the security wherewithal needed to rise beyond adopting more than one public cloud service in their production environments, he says.
In general, Jefferson says, developers are not likely to consume security technologies on a public cloud that can’t be invoked via an API. Because of that issue, many IT organizations are discovering that the security platforms they have employed on-premises simply can’t be lifted into the cloud. That issue, he says, creates a level of friction inside the organization that inevitably hampers usage of cloud platforms more than any other challenge an IT organization faces. Cloud applications require a DevSecOps approach that developers will view as a natural extension of existing DevOps processes, says Jefferson.
To achieve that goal, organizations need to make it easier for developers to secure their applications and invite IT security experts inside their organization to participate in, for example, scrum teams that collaboration build, deploy and manage applications. In fact, Jefferson notes most DevOps teams don’t even want to talk to a vendor’s sales representative; they prefer to be able to download code that they can test and deploy on their own before committing to buying a license.
It’s still relatively early in terms of appreciating the impact DevSecOps will have on improving IT security. But one thing is clear: IT security vendors that don’t make it simple for developers to invoke the capabilities they provide soon will be left behind.
