Tag: application security

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

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

What is ShiftLeft?

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

Are innovations and security at odds with each other now?

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

Here are some important statistics from ShiftLeft customers:
1. If you’re doing automated enforcement in ShiftLeft you are fixing 91.8% of the vulnerabilities
2. If you’re not doing automated enforcement but you’re using a modern solution like ShiftLeft you’re fixing 58% of vulnerabilities in the first sprint.
3. If you’re still stuck with a legacy solution, your team isn’t fixing 60% of the vulnerabilities ever – forget if it’s the first, second or third sprint. It becomes technical debt.
So why aren’t people adopting modern solutions like ShiftLeft and ditching legacy solutions?

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

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

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

There are two important application personas:
- Application security: Application security has a mile wide and inch deep knowledge of applications and who is compensated on app security improvements.
- Developers: Developers have a mile deep but inch wide knowledge of software because they are so focused on their own code.
Both personas are required because application security cannot fix vulnerabilities in applications, the developer must do that. But developers aren’t going to want to do that unless that work is prioritized by application security.

Key takeaway? Collaboration is essential to application security.

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

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

What Runtime Application Self-Protection (RASP) Doesn’t Solve

RASP, or Runtime Application Self-Protection, is a modern security technology that protects web applications from attacks during runtime. The technology is an important complement to defense systems that focus on the perimeter, but RASPs also have weaknesses that can introduce their own vulnerabilities.

What are RASP’s strengths and weaknesses in protecting against modern security threats? Are there better solutions that offer more in-depth insight into attacks as well as detect suspicious behavior?

A deeper dive into RASP

Gartner defines RASP as “a security technology that is built or linked into an application or application runtime environment and is capable of controlling application execution and detecting and preventing real-time attacks.” Many IT organizations already deploy them, often in conjunction with other security solutions.

An ideal RASP promises:

Deeper-rooted code-level visibility into applications
Passive and active incident response features such as monitoring/alerting and blocking modes
Configurable options to log, alert, challenge, or block malicious behaviors
Support for many languages and execution platforms
Autonomous operation without manual tuning
Coverage for a broad set of vulnerabilities, including OWASP top 10
Integration with secure software development lifecycle (SSDLC) and monitoring tools.

RASP fills the security gaps left by a perimeter defense model like Web Application Firewall (WAF), which protects both legacy and modern applications. Based on these promises, RASP may look like the necessary missing piece of your security stack. In practice, however, it has weaknesses. Let’s dive deep into RASP to understand its advantages and shortcomings.

RASP advantages

Watches rather than predicts

Similar to WAF, Runtime Application Self-Protection works by blocking malicious behavior but does so without extensive need for preset rules and tuning. Rather than building a trained model or predicting behavior, RASP watches the application at runtime to see that those actions are actually performed. For example, a request call to a database occurred, a shell command is executed, or that a file is opened.

DevOps-centric attack visibility with better SSDLC integration

RASP provides visibility into how an application is being attacked, providing better intel and alerting security personnel and developers to the exact vulnerable code. Developers can use this information to modify the codebase and eliminate security vulnerabilities. RASPs may also offer the option to integrate directly with the application development lifecycle to pinpoint vulnerable code based on attacks observed in the production environment.

No training required

An ideal RASP doesn’t need to be taught what bad behavior looks like. That’s because it is tied to the application stack, so knows what the application should and shouldn’t be doing. When the application’s behavior changes, it’s no problem for RASP to adapt because the security is based on the application and not on a set of predefined rules and educated guesses.

Provides time to fix vulnerabilities

Programmers are responsible for developing and releasing new applications and features, and subsequently developing updates and patches as vulnerabilities and bugs are discovered. It can take organizations months to apply patches which creates a window of opportunity for hackers. Because RASP protects against incoming attacks, it provides the engineering team time to fix vulnerabilities free from the pressure of working during a crisis. It is synonymous with WAFs’ virtual patching.

Cloud agnostic

The RASP protection design is rooted in modern software engineering techniques such as instrumentation, dynamic hooks, and secure SDKs. It works by implanting sensors in the existing application code to monitor and control critical execution points in real time. Utilizing these techniques, RASPs become part of the application, allowing them to remain protected independent of their deployment environment. RASPs may not require network calls and work in any deployment architecture, including on-premise, cloud, and containers.

RASP disadvantages

Confined context

Purely from a technical viewpoint, since RASP sits within the application framework, it may look to be a smarter alternative to perimeter defense solutions like WAF. Practically, however, no application is self-contained; they interact with a multitude of other services and components. Consider that each application module can be deployed in different endpoints, further limiting the RASP’s visibility and capabilities.

Use case abuse

We frequently hear about large companies breached with modern application attacks like Broken Object Level Authentication (BOLA). Attackers substitute their resource ID in the API call with a resource’s ID belonging to another user. The lack of proper authorization checks allows attackers to access the specified resource resulting in BOLA. Since the input remains consistent with what the application received before, RASP finds no reason to inspect and will let it pass through. Attackers can abuse similar use cases like Broken Function Level Authorization (BFLA) without RASP suspecting the intrusion. Protection for such attacks requires building broader business context from the application, which RASPs lack.

Normal API request by Robby to fetch his profile

BOLA Attack: Robby changes his user id in the
request and reaches Ava’s profile

<code>
REQUEST
===============
GET /customer/
12548
/profile
Host: shop.store
Cookie: session=
5015ee5d-6133-cab4874b
Accept: application/jsonRESPONSE
===============
HTTP/1.1 200 OKContent-Type: application/json{“id”:
12548

“fName”: “Robby”

“lName”: “Saxton”

“phone”: “202-555-0128”

“ssn”: “987-65-4325”

“address”: “3454 Crummit Lane,

Omaha, NE

68114”
}

</code>

<code>
REQUEST
===============
GET /customer/
12549
/profile
Host: shop.store
Cookie: session=
5015ee5d-6133-cab4874b
Accept: application/jsonRESPONSE
===============
HTTP/1.1 200 OKContent-Type: application/json{“id”:
12549

“fName”: “Ava”

“lName”: “Rose”

“phone”: “340-5556-577”

“ssn”: “449-26-2109”

“address”: “4702 Gordon

Street, Chino, CA

91710”
}

</code>

Missing distributed protection

Since RASP only has visibility for the current application context, additional application-level Distributed Denial of Service and Bot protections cannot be efficiently solved by RASP. A perimeter defense solution can completely isolate that traffic, absorb it, and take defensive action even before the attack hits the application stack.

Intrusive deployment

RASP requires an intrusive deployment model and is highly dependent on the platform and codebase used for the application to be beneficial. It has to be deployed along with the application in the application stack. Some organizations may not feel comfortable deploying RASP for critical services, thus needing to invest more in other security solutions that add cost and maintenance.

Deployment challenges

Conceptually, RASP can do more in-depth protection sitting within the application stack. But there are practical challenges in managing and updating a RASP component deployed at every endpoint. RASP adds additional performance overheads not just on the application execution but also on the dedicated effort required to deploy, tune, and monitor itself and the runtime environment. And to determine proper placement that protects all assets, RASPs may need you to gather internal information about the application and trace data flow.

Unintended consequences

Though RASP’s goals are noble, its deployment can create unintended consequences that produce pain points. For example, situations may require the rewriting of software execution at the last minute, introducing risk from a support/incident response perspective, particularly as applications are modularized and supported by distributed teams.

Performance degradation and impact on service level agreements

In today’s high-performing environments, where availability is expected to be at least four 9s, downtime could severely impact SLA’s, resulting in lost revenue and damage to the company brand. RASPs might impact the application functionality even in monitoring mode as they wrap over existing essential library functions. Since RASP does not learn the business context, it may predict that a perfectly valid use case is malicious. Allowing RASP to stop code running in production amid an attack may pave the way for an effective (and self-imposed) Denial of Service (DoS) engine.

Too much reliance

RASP should be considered as another layer of control, but human behavior can lead to too much reliance on RASP for application protection. This behavior can generate a pile of vulnerabilities that attackers can use in conjunction with other techniques to exploit the application. For in-house-developed proprietary libraries, RASP tools are still not substitutes. The Secure Software Development Lifecycle needs to be followed with other formal methods such as source code reviews and automated tools, like static application security testing and dynamic security application testing, to identify and remediate vulnerabilities in both the source code and the application.

You deserve better

RASP is not a plug-and-play technology; it requires a full cycle of validation with existing applications to ensure functionality and performance are not adversely affected. What RASP makes up for in some areas it lacks in others.

There is a need for a better solution in the application security world that can provide more in-depth insight into attacks as well as detect anomalous behavior. Traceable provides this hybrid approach by combining distributed tracing with intelligent analytics to build a complete picture of your microservices and protect them. Don’t just cover one part of your application; defend it all.
‍

If this sounds like a smart approach to detecting and treating modern security threats, then we should talk. View a demo of Traceable in action.

June 9, 2021

Security Risks With No-Code/Low-Code Tools

As the popularity of no-code and low-code tools grows, so, too, do security concerns

The demand for new applications is growing at a rapid rate. Many individuals and business units will not tolerate delays. As a result, citizen developers are stepping in, some of whom may be sanctioned by the company while essentially operating as shadow IT.

Common to both groups is that they increasingly are aided by the wide availability of no-code/low-code development tools and platforms on the market today. Such solutions abstract away many coding tasks, offering developers a visual studio or palette to create applications by dragging and dropping software components and smaller apps.

No-code/low-code tools offload tedious chores from professional developers, allowing them to work more efficiently. For those without that expertise, these tools enable people who have intimate knowledge of the business create their own applications and automate processes.

Development is not only faster but less structured. As such, these technologies in the hands of those not trained in security can introduce risk.

There are many ways citizen developers can expose a business to cyber risks. One common issue in many companies is that citizen developers (like their professional counterparts) do not want to reinvent the wheel. If they can find an existing or open source component to an application, they might freely use it when developing an application. For example, rather than hard coding a front-end mobile user interface for different platforms, they may just take existing ones and use them for their new applications. Similarly, if they want their application to perform real-time analytics, they could use an open source events stream engine. And if they want to create an interactive chatbot, they might use open source cognitive apps. The problem is that they select these no-code/low-code apps with very little vetting of the code components they’re using.

Another common issue is that a citizen developer might ignore built-in security features in a component that makes up their composite application. For example, they may choose not to password-protect a database to simplify its use. Or they may decide to forgo best practices and send data across public networks unencrypted.

There are many choices like these where attention to security is needed. Yet, most citizen developers do not even know to be on the lookout for potential security weaknesses.

Layering in Security Before, During and After Apps Are Created

Obviously, citizen developer applications must be tracked, vetted and fixed before potential vulnerabilities are exploited by attackers.

To do that, security needs to be integrated throughout an application’s life cycle. It is no longer enough to only test for vulnerabilities after an application is developed and let it operate unchecked forever. Additionally, security must be real-time instead of reactive. It must constantly examine the elements of an application as they operate and are modified.

Cobbling together components using no-code/low-code techniques introduces additional issues. While the individual components may be trusted, the use of several components together might expose data or provide a weakness that can be exploited. Additionally, a composite application that is secure today may no longer be so if a new vulnerability emerges for one of the software elements within the application.

What many organizations are finding is that they need to marry DevOps and security. Hence, the growing focus on DevSecOps in the industry. DevSecOps is increasingly necessary to find weaknesses and vulnerabilities in modern applications composed of loosely coupled components.

The constant refreshing, updating and replacement of applications dictate that security must be an integral part of the entire life cycle of an application. Again, another reason to bring security into the application life cycle, just as DevOps does for development and deployment.

And the complexity of applications built, even when using low-code/no-code methods, means security needs to be more sophisticated to understand hidden dependencies in today’s loosely coupled applications. Any security solution cannot be passive. Simple scanning for known vulnerabilities is not enough. A solution must understand the way components of a citizen developer application change over time and interact with one another.

The bottom line is that cybercrime protection must be implanted at the code level, and secure coding practices must be instituted, especially when citizen developers are driving application development.

June 7, 2021
Web Application Security is not API Security

Do you follow the same procedures to secure a web application as you do an API? Is there a difference between the two?

We’ve spoken about API security quite a bit in the past few months because we believe that there are critical differences between API security and traditional web application security. A lack of understanding of those differences is dangerous.

Let’s look at the differences between the two and why you should treat API security differently from application security in general.

What is API security?

API security is the practice of defending web APIs against attacks. Building APIs, typically with microservices as the foundation, has become a growing trend. Many mobile applications and websites send and retrieve data using APIs, even if the end user is unaware of this fact.

APIs are different from traditional web applications, and those differences can lead to critical security issues.

What Makes APIs Different From Traditional Web Applications?

I’ll answer that question with a picture, then proceed to “drop the mic.”

Here’s the entire Netflix architecture, comprised of about 700+ microservices. (Source)

(Picking the mic back up.)

The above picture illustrates why APIs are fundamentally different from traditional web applications. What was once one request to one server has become dozens or hundreds of requests to dozens or hundreds of microservices.

Previously, the work was relatively easy; defend one large application. Now, you have to protect hundreds of small web applications and the data they access. Authentication and authorization don’t look the same. The built-in session management of your favorite framework has gone out the window. Each microservice is its own little kingdom.

In addition, you now have to know where all of these API endpoints reside, what version they’re running, and how to scale them when demand increases.

Finally, changes to the development and deployment environment cause changes in how malicious actors attack applications. Are you familiar with the new ways attackers target APIs?

What Are the Most Significant Threats Against APIs?

The OWASP API Top 10 project outlines 10 dangerous risks with APIs. (See this post for the breakdown.)

Instead, let’s look at the big themes the API Top 10 brings to the forefront. Then we’ll discuss some specific breaches that illustrate what happens when APIs are vulnerable.

Authentication and Authorization Win Top Prize

Okay, maybe “Most Likely To Get You Hacked” isn’t much of an award, but authentication and authorization are the most prolific and dangerous API security flaws.

Authentication and authorization in APIs feel like a new world for many developers. A development framework doesn’t manage a session, but instead, applications pass JSON Web Tokens (JWT) around with claims attached. In a nutshell, every microservice must verify the caller’s identity and permissions before performing any work on their behalf.

As the number of APIs grows, it’s more likely that developers will miss some authorization checks, and a data breach is waiting to leap out and strike when you least expect it.

API Endpoints Are Everywhere

I remember taking my two-year-old daughter to Disney’s Magic Kingdom during spring break. I had to slip a kiddie leash on her to make sure she didn’t disappear in the crowd. It was challenging to keep track of only one child in that vast mass of people.

An explosion of microservices fills your infrastructure with a crowd of endpoints, and kid leashes don’t seem to fit Docker containers very well. It’s easy for APIs to disappear.

Unfortunately, these “shadow APIs,” whether spun up by a developer for testing purposes or just an old version left out in the wild, can become a point of attack. They may not be secure, and if you don’t know they’re still publicly exposed, someone could be attacking it without your knowledge.

Examples of Real API Vulnerabilities

Let’s illustrate the differences between API and web app security by looking at real vulnerabilities.

Shopify “Collaborator” Vulnerability

Security researcher Uzsunny found a critical flaw in the Shopify “collaborator” functionality that allowed an attacker to assign themselves the “collaborator” role on any store. This feature unlocks all sorts of administrative functionality.

It turns out that the API endpoint that handles this collaborator business logic didn’t verify that the request to add a collaborator to a store came from the store manager. Therefore, anyone could call that endpoint with the right arguments and get admin rights to any store on the Shopify platform.

Check out our detailed post on how this vulnerability works and why it’d be hard to detect.

Facebook Authentication Bypass Using Shadow APIs

Obscurity isn’t security, and determined attackers will find forgotten API hosts. The AppSecure cybersecurity research team found a way to gain access to any Facebook account via a couple of API endpoints Facebook forgot existed. The AppSecure team received a $15,000 bug bounty.

Although found in 2016, this bug illustrates a kind of vulnerability prevalent in API architectures. This bug was subtle but demonstrated how the smallest crack could let an attacker run amok.

The bug existed in Facebook’s password recovery logic. When a user requested to recover their account because of a forgotten password, they received a random six-digit code via text message. They enter the code in the browser, which sends an API call with the code.

Facebook placed rate-limiting on the endpoint to protect against brute-force attacks. The API blocked client requests after 10 failed attempts. However, API endpoints existed on other hosts, and Facebook’s engineers didn’t realize it. An attacker could send payloads to “beta.facebook.com” and “mbasic.beta.facebook.com” and brute force the recovery code. These endpoints didn’t have the ten try limit.

Check out our detailed post on this vulnerability for more on how modern app sec tools probably would’ve missed this vulnerability.

Uber API BOLA Vulnerability

Broken Object Level Authorization (BOLA) is number one on the API Top 10 list. Uber’s API had this vulnerability. Thankfully, it was discovered by security researchers before malicious actors did damage (as far as we know). But it illustrates well how dangerous BOLA can be.

The vulnerability leaked sensitive information, including an authentication token that could be used to perform a full account takeover.

The vulnerability appears when a new driver joins the Uber platform. The browser sends the “userUuid” to the API endpoint, and the API returns data about the driver used to populate the client.

Unfortunately, the API endpoint didn’t check if the calling client had the authorization to view its returned details. An attacker could add another “userUuid” and get a sizable JSON object with the other user’s account details, including first and last name, email address, and user identifiers.

This vulnerability illustrates that revealing too much information is dangerous for any API (Excessive Data Exposure is number three on the Top 10). Also, inadequate authorization checks can lead to account takeover with minimal effort.

Check out our detailed post to learn more about this vulnerability.

The Future of API Security

Application security technologies such as Web Application Firewall, Next Generation Web Application Firewall, and Runtime Application Self-Protection don’t typically find the kinds of vulnerabilities we’ve discussed. These attacks present as ordinary traffic, so many defenses let them through.

The future of API security lies with business logic. Application security tools have to understand the application’s context and business logic to know that non-managers shouldn’t be adding collaborators to a store or that a client shouldn’t access that user ID’s information.

Traceable AI uses machine learning to learn the application’s business logic, so these types of attacks are found and stopped. See Traceable AI in action and see what the future of API security looks like.

May 11, 2021
Modern AppSec and Supply Chain Attacks – Three Challenges
The recent news about the SolarWinds breach has focused on the difficulty and challenges a supply chain attack presents. In the case of what Microsoft is calling “solorigate,” the attackers modified a dll deep inside a trusted application, which was then deployed into over 18,000 enterprises and government organizations, where it would then create a live back door for the attacker to exploit. The Microsoft Threat Intelligence Center (MSTIC) recently published details about how the SolarWinds attack worked and attempted to avoid detection.

Supply Chain Attacks and API Security

In this specific case, the exploit targeted a traditional, legacy application as part of SolarWinds Orion, an IT inventory management and monitoring application. The attack was the result of extensive planning and resources, which appear to be the work of a state actor. The immediate focus must be on mitigation of the current attack. Still, it is also essential to understand that supply chain attacks like this should be considered in the future as modern cloud-native applications become the norm.

The evolution of cloud-native and modern applications where the functionality is decomposed into microservices, each running independently of each other, presents several new challenges for security and IT professionals to address. Specifically, the underlying application programming interfaces (APIs) introduce new attack surfaces where API security is paramount. The OWASP API project has enumerated 10 critical API level threats that are substantially more important in the era of modern, cloud-native applications.

These three trends – microservice proliferation, application change and porous perimeters – create an environment where attacks can flourish and where IT and security teams need to consider revisiting their application security practices and controls.

Microservice Proliferation

Inherent in adopting a cloud-native architecture, one characteristic is the decomposition of the monolithic architecture into atomic services. Microservices enable business application teams to operate more efficiently and innovate. This approach also results in a compounding of the number of independent services, where each microservice is a potential source for the injection of a supply chain attack. In the case of microservices, rather than compromising an entire system, an attacker has more opportunities.

The challenge facing defenders is how to manage the proliferation of hundreds or thousands of new microservices, each with its unique code base and API calls, between services? On one hand, traditional web application firewalls (WAFs) can play a role, attempting to protect the edge, but on the other hand, WAFs do not account for the underlying complexity of the web application and microservices. One key question to ask is, will their rule-based approach adequately detect and prevent this kind of threat?

Continuous Application Change

Speed and rate of application improvements and enhancements have accelerated as teams adopt DevOps practices of continuous delivery and continuous deployment. Business expectations of faster delivery and reduced cycle time have naturally led IT teams to embrace and adopt DevOps practices of CI/CD, which, when adopted, lead to significantly shorter cycle times between changes. The industry has seen remarkable improvements in delivery speed; organizations have gone from quarterly releases to weekly and even hourly changes – sometimes, even faster. For example, a team at Goldman Sachs releases every few minutes and Netflix releases thousands of times per day.
‍
In a traditional application where new code is delivered lethargically, it might have been possible to keep up with the pace of change and mitigate security threats. However, in the age of microservices and cloud-native applications, it is unrealistic to maintain full awareness of the application’s state and associated microservices. Change is happening too fast and at too many internal points for a security leader to adequately manage their risk profile.

Relatively Porous Perimeter

Because applications are no longer monolithic installations that reside behind a defense-in-depth fortress, they are much harder to protect. Indeed, the principles of zero-trust are essential when designing and managing modern applications. The reality is that for every microservice (both internal and external), there is a library of interfaces that enable the microservices to communicate with each other (internally), with third-party service providers (externally) and with end users through an established UI.

Additionally, how many of your applications have a “call home” feature where they communicate health and usage data with their vendor? While many vendors use this information to improve the quality of their service, it is also another potential threat vector to consider.

The web application firewall and traditional approach to security provide only a degree of protection, as the nature of modern applications encourages the use of SaaS services, third-party services and other resources in the interest of faster delivery. This complicates the challenge of delivering a secure application as well as monitoring it as it is running.

Suggestions to Address API Security

We’re still early in the cycle of the SolarWinds breach, and the aftermath will be extensive and expensive, as will the lessons learned as the damage is measured. However, one thing remains true. The threats continue to evolve, which means that security professionals (strike that) IT professionals (because security is everyone’s responsibility) need to renew our focus and commitment to delivering secure, reliable and trustworthy applications.

There is no perfect protection or 100% secure approach; instead, it is a question of how to establish layers of defense where each layer of security reduces the overall risk exposure. Ultimately, you want to have the ability to:
- Prevent the risks in the first place (software supply chain and zero-trust architecture) and
- Detect and react to adversaries who may be attempting to exploit your systems.
Specifically, here are several recommendations to improve your security posture and lower your exposure:
1. Invest in processes and tools to help validate your supply chain. A “trust, but verify” approach is critical in the development stages. You should look at tools like Sonatype and others that can help reduce the risks in your software supply chain.
2. Adopt a zero-trust approach to the design and implementation of microservices.
3. Maintain awareness and insight into the current state of your APIs and your present risks (too many organizations cannot keep up with the pace of DevOps change).
4. Augment your perimeter with processes and practices to have “zero-trust, but verify” in production. You need to observe the behavior of each of your microservices and detect anomalous behavior between your microservices.
- Should microservice A be communicating with microservice B?
- Is the data flow between microservice A and microservice B typical?
- Are there suspicious behaviors or patterns that indicate anomalous behavior?
Traceable.ai helps you detect and react to threats to your cloud-native and modern applications where API security is now mission-critical. If you’re interested in learning more about how you can improve visibility into your modern applications and your overall security posture, the best way to start is to view a quick recorded demo of Traceable.ai.
May 11, 2021
Is Open Source More Secure Than Closed Source?

There’s no getting around the fact that security is one of the most essential factors in day-to-day operations for most software developers. From proprietary code to sensitive customer data and everything in between, there are hundreds – if not thousands – of crisis scenarios that can result from gaps in security.

Data security is an issue that every company faces, no matter how large or small. Developers look for security solutions that follow today’s data and application security best practices in order to reduce risk and provide the most secure experience possible to the end user.

A common debate among both users and developers is whether open source software is more or less secure than closed source alternatives. While there are a variety of different schools of thought as to what makes for a truly secure environment, there is good reason to believe that open source software is the superior option for those looking to prioritize security.

While open source code may not be inherently more secure than its closed source brethren, here are a few reasons why it almost certainly can be — so long as you take the right approach.

Open Source Offers True Transparency

Both well-established tech giants and up-and-coming startups work with some of the brightest minds in the development community to bring valuable proprietary software products and services to market. At the end of the day, however, users have no choice but to trust what a vendor says about how a particular piece of software actually “works.” Since you can’t see the code itself, there’s no way to really verify whether or not what you’re being told – about features, functionality and security – is accurate.

This can be problematic for a host of reasons—not least of which being the threat of potential security flaws. A company might boast about its commitment to user security and privacy through savvy public relations and product marketing efforts. But, by no means does this provide the user with anything more than lip service if the code doesn’t measure up; even if it’s rock-solid, the question of “How truly secure is this?” can never be answered with confidence.

Open source software offers greater transparency to the teams that use it; visibility into both the code itself and how it is maintained. Giving organizations access to the source code allows them the opportunity to evaluate the security of the code for themselves. Additionally, users have more visibility into how and what changes are made to the code base, including the pre-release review process, how often dependencies are updated and how developers and organizations respond to security vulnerabilities. As a result, open source software users have a more complete picture of the overall security of the software they’re using.

Open Source Encourages Community Input

Another major benefit is found in the communities which drive the growth and development of open source software. The vast majority of open source software is backed by communities of forward-thinking developers, many of whom use the same software they build and maintain as a primary means of communicating with team members. Open source developers and the communities around the software value users’ input to a significant degree, and many user suggestions end up getting incorporated into new versions. The community involvement and investment ultimately leads to many more responsible vulnerability disclosures than would likely occur if the software was closed source.

When vulnerability reports do occur, they tend to be more detailed because the code is open source; often, they even come with code suggestions for how to remedy a given issue. This is incredibly helpful and can dramatically speed up patching the vulnerability, as it allows developers to move faster without spinning wheels and getting stuck in the diagnostic process.

Faster Security Updates

Within the framework of closed source software, users are at the mercy of the companies behind those products or services when it comes to receiving software updates―open source tends to be a different story. Fully open source projects even allow users and developers to take things into their own hands and contribute feedback and fixes, should they choose to do so.

More often than not, updates and fixes for high-profile closed source applications involve a great deal of complex planning. If it’s not in the budget, for example, users may not see a new update for weeks, months, or even longer—security flaws or not.

In most circumstances, open source tends to move faster than closed source when it comes to iterating and releasing new versions. This is true for a handful of reasons, including the fact that open source software tends to have more eyes on the source code at any given time, as well as a community-driven interest in bettering the product whenever possible. If a significant security flaw is uncovered, users may even choose to fix the code themselves, resulting in a level of control that can never be achieved in a closed source environment.

Open Source Offers Flexibility, Collaboration and Enhanced Security

An open source methodology, in and of itself, is no guarantee of security, but it does offer teams greater insight and control over the software they rely on. And as open core and source-available software are more broadly adopted, they offer a wealth of opportunities to build incredibly secure environments without sacrificing usability for end users or support from official maintainers.

April 14, 2021
4 Ways SASE Fuels DevOps Productivity

Many enterprises are adopting secure access service edge (SASE) solutions as part of their digital transformation efforts. SASE, in a nutshell, merges together SD-WAN and security stacks to deliver secure networking and improved WAN performance, making it a logical choice for cloud-enabled businesses going through the throes of digital transformation. However, SASE offers other benefits, which may be of particular interest to DevOps teams.

Let’s take a look at four ways SASE can enhance the productivity of DevOps teams.

Reducing Collaboration Challenges

SASE reduces the challenges associated with team collaboration. SASE, by design, integrates WAN optimization with cybersecurity. Today’s DevOps teams need to work together, despite being physically separated, and must have reliable, secure connectivity amongst the team. “DevOps are all about time-to-market, and DevOps teams are looking for ways to shorten their CI/CD cycles. A critical part of that process is reducing their dependency on the networking and the security teams,” said Boaz Avigad, director of product marketing, CATO Networks. “Since SASE solutions already provide optimized performance and robust security, DevOps [teams] are free from waiting for infrastructure teams to provision the necessary resources. SASE provides DevOps the control and operational cadence they need without compromising performance or security.”

SASE Improves Networking

SASE improves overall network performance with integrated load balancing and failover capabilities. DevOps teams cannot afford to lose connectivity, especially when rolling out new iterations of software or resolving bugs. “For DevOps teams, fast and reliable application performance is critical,” said Avigad. “SASE architectures free DevOps [teams] from worrying about the infrastructure by connecting all the company’s edges, data centers, mobile users and cloud resources, with the same self-healing, secure and fully optimized global network. Should a line fail or a route become congested, SASE automatically switches to an alternate path.”

Better Security Built In

SASE helps to secure DevOps projects with native cybersecurity capabilities. When properly implemented, SASE integrates numerous security technologies directly into the network stack. “DevOps teams worry about information interception and protecting their applications from threats. All security services share a single, unified context, improving insight and closing the gaps in legacy security architectures; gaps attackers often exploit,” said Avigad. “SASE not only includes NGFW, IPS, SWG, AV and MDR services, it also converges them together into a single-pass architecture.”

SASE Removes DevSecOps Burdens

SASE secures internal applications, along with the interactions with those applications, which in turn helps to reduce the burdens on DevSecOps team members. Applications that run over SASE/SD-WANs are further secured by zero-trust network access (ZTNA) and software-defined perimeter (SDP), technologies that help to keep all interactions between an endpoint and an application secure. “Many proprietary applications are too sensitive to run over the public internet. SASE protects those applications by obfuscating traffic, protecting all entry points with a NGFW and restricting access with its zero-trust architecture,” said Avigad. “All internal application traffic is also continuously inspected for threats.”

Adopting SASE for DevOps teams is beginning to make a lot of sense. The technology addresses many of the pain points that DevOps teams experience as businesses drive toward digital transformation. What’s more, the security benefits offered bring forth additional productivity, while also unifying the security stack.

April 14, 2021
42Crunch API Security Platform Now Available On-Premises

42Crunch has announced that the scanning tools it provides to enable DevOps teams to secure application programming interfaces (APIs) can now be deployed in on-premises IT deployments.

Previously only available as a cloud service, the 42Crunch API Security Platform has also been updated to provide expanded support for the OpenAPI specification for REST interfaces defined by the OASIS standards body.

Finally, the 42Crunch API Security platform now allows IT teams to share collections of APIs among specific teams and users with different levels of access in addition to providing integration with third-party identity management platforms.

Dmitry Sotnikov, chief product officer for 42Crunch, said the on-premises edition of the API scanning platform will make it possible for IT organizations, including those that require all the platforms they run to be deployed in an IT environment, to exercise more control over and extend their DevSecOps workflows to include scans of APIs.

Cybercriminals are increasingly targeting insecure APIs because they potentially provide access to a trove of data, Sotnikov noted. Those same APIs also enable cybercriminals to compromise an entire software supply chain, Sotnikov added.

At a time when more organizations are deploying APIs, thanks to the rise of microservices, it’s apparent there is a greater need for a tool that dynamically scans APIs for vulnerabilities before they are deployed, said Sotnikov.

In general, Sotnikov said IT organizations are becoming more sophisticated in their approach to securing software. Ford Motor Co., for example, is using the 42Crunch API Security Platform to secure both internal and external APIs, Sotnikov said. 42Crunch claims its revenues increased 900% in 2020, with more than 150,000 users of the platform.

As organizations of all sizes become more dependent on software, cybersecurity teams are now reviewing how that software is constructed. Of course, responsibility of security is still shifting left as part of the overall transition to DevSecOps best processes, but Sotnikov said cybersecurity teams still want to verify for themselves that whatever software is deployed is secure. IT organizations are moving away from a “whack-a-mole” approach to security as they embrace DevSecOps, Sotnikov added.

Unfortunately, APIs don’t always receive the level of attention they deserve. Many developers still tend to view them as an afterthought, and once deployed, it’s not uncommon for APIs to languish for years without being reviewed or updated. Making sure APIs are secure requires dynamic scanning processes to be baked into DevOps workflows if organizations want to ensure the integrity of their software, said Sotnikov.

APIs are, of course, everywhere now. The days when a handful of APIs were exposed to share data with a limited number of customers and partners are long over. There are almost no applications built and deployed today that doesn’t expose myriad APIs. Cybersecurity teams obviously can’t keep pace with the rate of change being made to those APIs, as new ones are added and others updated or replaced. The onus for securing all those APIs is, now more than ever, clearly on the DevOps team.

April 1, 2021
Sonatype Acquires MuseDev to Add Code Analysis

Sonatype today revealed it has acquired MuseDev, a provider of a code analysis tool, in addition to updating its Nexus platform for discovering vulnerabilities in software supply chains.

Muse analyzes code each time a pull request is made, which makes it easier for developers to discover and address issues long before they commit code. Muse is integrated with 24 pre-configured code analyzers for GitHub, GitLab and Bitbucket repositories. It then analyzes each pull request to surface bugs, as part of automated code review, and includes analysis of interprocedural information flow and thread safety issue analysis, along with guidance to fix any bugs discovered.

In addition to adding support for Muse, the latest edition of the Nexus platform integrates a container firewall from NueVector along with a set of tools for identifying and providing guidance on how to address misconfiguration issues that frequently arise when developers employ open source Terraform software to programmatically manage infrastructure as code.

Finally, Sonatype added tools to provide better guidance on the implications of open source licensing terms attached to various projects, while at the same time starting its own community for organizations migrating from Bintray and JCenter, now that those tools have been sunsetted.

Brian Fox, Sonatype CTO, said the expectation is Muse will create an opportunity to introduce the complete DevSecOps portfolio to developers as they analyze code. Most developers are keenly interested in both optimizing and securing their code. They would just prefer to achieve that goal on their own versus being informed of an issue after code has been committed to a repository managed by a larger DevOps team, noted Fox.

An advanced development pack was added to the Nexus platform last year to make it easier to surface dependencies in code that are vulnerable to threats. It applies machine and deep learning algorithms to automatically identify and block software supply chain attacks based on typosquatting and malicious code injections. Collectively, these tools give developers control over third-party open source code, first-party source code, infrastructure as code and containerized code, Fox said.

Sonatype claims it now counts 70% of the Fortune 100 as customers, and supports more than 2,000 commercial engineering teams. In 2020, it claimed it saw a 35% annual growth in Nexus repository installs, which now stands at more than 250,000 instances employed by nearly 15 million developers.

Overall, it’s not clear how much progress is being made toward embracing DevSecOps best practices. Sonatype, however. is making a case for putting DevSecOps tools directly into the hands of developers to address software supply chain security. In the wake of some recent high-profile breaches involving software supply chains, that approach may soon gain additional traction. After all, for all the encouragement being provided by application development team leaders these days, there’s nothing quite as effective as providing developers with a set of tools that enables them to achieve that goal on their own terms versus requiring them to follow a set of procedures dictated by a DevOps management team.

March 16, 2021
Linux Foundation Project Secures Software Supply Chains

The Linux Foundation today embraced a sigstore project founded by Red Hat, Google and Purdue University to make it simpler for developers to employ cryptographic software, enabled by transparency log technologies, to secure software supply chains.

Luke Hinds, security engineering lead in the office of the CTO at Red Hat, said he and Dan Lorenc, a staff software engineer for Google, led a small team creating a lightweight mechanism for signing software artifacts, such as release files, container images and binaries, in way that creates an immutable, tamper-proof log.

Now, the goal is to take that project to the next level by contributing it to the Linux Foundation, at a time when the focus on software supply chain security has increased in the wake of a spate of high-profile breaches. As part of that effort, a free service, based on sigstore, will also be made available by the Linux Foundation to make the cryptographic software easily accessible to a wide range of developers.

Hinds said one of the reasons that artifacts are not signed by developers is that the current processes employed are too cumbersome. The cryptographic software is designed to be integrated as an extension of existing workflows, Hinds noted.

Because the log created is immutable, everyone participating in the software development process, including auditors, can now transparently track chain of custody for any software artifact, Hinds said. At its core, sigstore creates a set of short-lived ephemeral keys with a trust root based on an auditable public log.

Existing approaches rely on digests stored on insecure systems that are susceptible to tampering. Cybercriminals can, for example, swap out digests if they can gain access to compromised credentials. Those types of targeted attacks can be thwarted using sigstore, because the log management system that underpins it is immutable, said Hinds.

Of course, no system for securing software supply chains is going to be useful if developers won’t employ it. Key management, key compromise/revocation and the distribution of public keys and artifact digests are challenging to manage. Developers, then, need to determine which keys to trust in addition to learning how to sign them when different platforms are employed. Digests and public keys are also often distributed across vulnerable websites susceptible to hacks, or stored as a README file on a public git repository.

As organizations embrace DevSecOps best practices, it’s only a matter of time before the entire software supply chain comes under greater scrutiny. Ultimately, the issue will come down to finding a way to secure those supply chains, either from the top down by deploying and maintaining a platform, or simply making it easier for developers to better secure artifacts from the bottom up.

Regardless of approach, the signing of software artifacts should, one way or another, become more routine in the weeks and months ahead. The biggest challenge will be overcoming the simple inertia that currently exists among developers who routinely ignore the whole process.

March 9, 2021