Posted on

Unveiling Vulnerabilities via Generative AI

Code scanning for vulnerability detection for exposure of security-sensitive parameters is a crucial practice in MuleSoft API development. 

Code scanning involves the systematic analysis of MuleSoft source code to identify vulnerabilities. These vulnerabilities could range from hardcoded secure parameters like password or accessKey to the exposure of password or accessKey in plain text format in property files. These vulnerabilities might be exploited by malicious actors to compromise the confidentiality, integrity, or availability of the applications.

Posted on

POV on Best Fit Solution for Managing Secure Properties in MuleSoft

What Are Secure Properties?

One of the best practices in any application development is to keep the application properties configurable rather than hard-coded. This is achieved by keeping the properties in property files. These application properties are very much required in order to run the application. There will be different sets of application properties defined for each environment, such as development, testing, and production. We have different types of properties defined in the property files, such as host, port, log level, timeout, etc.

However, there are many configuration properties (such as User, Password, AccessKey, SecretAccesskey, client id, client secret, etc.) that are quite security-sensitive in nature and can’t be kept as plain text in application property files. Just imagine, if we keep the credentials as clear text in the application property file, anyone can read this information and misuse it. This could be more disastrous if this information is exposed to hackers or bad actors. 

Posted on

Superheroes Cannot Scale to Meet Application SLAs, But They Can Enhance Their Superpowers

Everywhere one turns, at least in the movie theater or small screen, there is a new superhero with some new power or focus. Given how important application or site uptime is, it’s a wonder that there isn’t yet a superhero for troubleshooting software problems. In a way, though, superheroes have existed for some time and have been the primary means of keeping applications running smoothly.

These Software Reliability Engineers (SREs) or support superheroes are highly skilled at finding a solution — if not the actual root cause — of issues based on their deep experience, knowledge, and intuition. But these software superheroes cannot scale to meet the new reality caused by the combination of ever-increasing complexity and the accelerating rate of application change. The combination is driving a steady growth in incident numbers, and observability tools are not the problem. The limitation is the amount of information the human mind needs to quickly absorb and analyze to resolve these incidents.

Posted on

Observability Tools Help Catch Application Failures — But Automating the Observer Is Becoming Crucial

A modern-day blessing for Site Reliability Engineers (SREs) entreats, “May the queries flow, and the pager stay silent.” This is because SREs, DevOps engineers, or support staff are constantly stressed about responding to their alert channels while keeping an eye on operational and performance dashboards to ensure their users have a good experience. Many frontline engineers are glued to dashboard monitor screens laid out in front of them. Assessing and responding to alerts is a top priority.

This approach involves both the observability tool and the observer, and they both have crucial roles. While various golden signals are continually monitored on the observability dashboards, it is up to the observer to provide the evaluation and intelligence to piece together details and know when and how to respond. This is especially apparent when there is some kind of problem. The observer has to determine what to drill down on and then where to go next in order to find the root cause. The observer is decidedly not automated, and there are finite limits to what they can take in and consider in their observations to develop proper context, validation, and, ultimately, to understand the root cause of a problem.

Posted on

Using Machine Learning to Find Root Cause of App Failure Changes Everything

It is inevitable that a website or app will fail or encounter problems from time to time, ranging from broken functionality to performance issues or even complete outages. Development cycles are too fast, conditions too dynamic, and infrastructure and code too complex to expect flawless operations all the time. When a problem does occur, it creates a high-pressure urgency that sends teams scurrying to find a solution. The root cause of most problems can usually be found somewhere among millions (or even billions) of log events from a large number of different sources. The ensuing investigation is usually slow and painful and can take away valuable hours from already busy engineering teams. It also involves handoffs between experts in different aspects or components of the app, particularly with the use of interconnected microservices and third-party services which can cause a wide range of failure permutations. 

Finding the root cause and solution takes both time and experience. At the same time, development teams are usually quite short-staffed and overworked, so the urgent “fire drill” of dropping everything to find the cause of an app problem stalls other important development work. Using observability tools, such as APM, tracing, monitoring, and log management solutions, helps team productivity, but it's not enough. These tools still require knowing what to look for and significant time to interpret the results that are uncovered.