Rogue Wave OpenLogic: A Review

No one says they don’t believe in secure applications, but a surprisingly large number of developers only take action to secure their apps after something serious has already happened. The impression is that the effort cost is too high, or there’s a feeling that we are impenetrable. After all, we don’t want to admit to a weakness.

Remember Heartbleed? In the modern era security is everyone’s problem. While the responsibility falls functionally on IT, developers, QA, and release managers also need to be mindful of everything that goes out the door. If something catastrophic does happen, it’s their heads on the block as well.

And nowhere do we run into more security variables than with open source components in our code. This concern is not a reason to avoid them, but at the same time special considerations need to be made so they don’t get organizations into trouble.

Technology breaks down into two categories, the pill or the candy. Candy is the cool new tech we want to buy and play with. The pill is what keeps us out of trouble. We all know that it’s usually more important to take your blood pressure medicine than it is to grab a lollipop. Security processes and tools are not fun for most, but it is the pill we all have to take.

The key to making security technology work, and make teams willing to spend effort on it, is to make sure it integrates with the existing tools and flow, and provides fast and useful metrics to act on.

Bring your own exploit - Open Source components

Such tools do exist and I recently spent some time with Rogue Wave OpenLogic product. They keep giving me cool stuff to play with. In the back of my mind during all my testing and evaluation I keep thinking about how this fits in the modern software delivery pipeline. Where releases and testing are automatic, and it’s a stream of code, not chunked delivery.

OpenLogic is an "open source" component review tool. It looks at all the components your software uses, in order to find out if they meet your organization's governance policies, as well as making sure there are no known exploits in the packages you use.

By using the common known vulnerability database CVE, built-in databases for analyzing components, and breakdown of common open source licenses, OpenLogic has the "logic" it takes to know what is going on in code. Above I put "open source" in quotes because they also allow you to manage private packages. Later I will explain why that is important.

OpenLogic has some limited freemium functionality based on the CVE. For the full analysis you need to buy an enterprise license. To do my testing I used the crawl agent on several small Java applications I have and also used a sample database that the OpenLogic team provided.

Testing OpenLogic was easy. Once you have setup a project in their cloud based portal (they have on-prem option as well). All you need to do to test the code is download the agent (scanner), on the machine where it resides. Presumably a location where you have a build.

When you run the scanner it reports back to your OpenLogic account the component names, versions, etc. Everything it needs to match component with policy, vulnerability information, and linked open source dependencies.

It also tells you quickly how your scan went.

Looks like I’m going to have to take a closer look at this build ...

Now all the data you need to evaluate the security of the components you used are found in the web-based platform. And depending on your permissions you can view the risk level of exploits, kick-off a workflow to request approval of a new package, and look at history of runs. It is also nice to use as an exploratory tool to look at the packages out in the wild and their current security ranking before you even use it.

Here is a look at the portal after several code runs, and established policies.

Looks like all versions as well.

The thing that makes this engine work is the vulnerability database and the organization's specific policies. Policies tell the scanner engine what components are allowed. This could be just a simple as "we don't want you to use it." To flat out, "No".

And the vulnerability database tells the team which packages are used that are A-Okay, have a risk, or a total problem after analysis has been done. Green, Yellow, and Red light. It not only applies to just named packages. It also applies to the version being used. Because it’s quite possible that newer or later versions were just fine while others were not.

When you are starting a new application the platform allows you to query approved components, and download them in-place. This is great to prevent sourcing components via a Google search and getting something harmful. This means that a developer doesn’t need to do anything more than they're used to except pay attention to a component’s approval status. If it is not approved they can always submit a request.

After you have all this good data. You can react. That’s the important part of leveraging any tool like OpenLogic: being proactive with your security not reactive.

The platform also allows business users (such as development managers or legal departments) to participate in the policy creation and monitor usage. This avoids the need to have ad-hoc conversations between IT, devs, and legal teams. Of course if you see red, you will be getting an email.

In addition to the user interfaces, there is an API that looks pretty comprehensive. Some notable REST calls are:

Package Distribution. I could actually use this in release automation to download approved packages during orchestration. Lots of coding but so cool.

GET https://olex-secure.openlogic.com/package_distributions/12086

Reviews and Requests. I can use this to see if a package is approved, or request its use in code. So this is also something I can put in release automation, with in-line code I can check if a package is approved so I don’t even need to worry about the scanning process. Or I can request the use of a new package during the first integration build where it is introduced. And it’s all done automatically!

GET https://olex-secure.openlogic.com/reviews/1034

My favorite part of the API is how you can introduce this platform into continuous integration / automated testing, orchestration, and release automation.

Breaking it down

After using the platform here are my thoughts.

Features I like:

• Private Packages - I was first worried that commercial components would be exempt, and I would have to use another tool, or just neglect their policy. But that is not the case. While you don’t get the same automated vulnerability detection, as this is up to the component vendor, you can manually add your commercial packages, and even add the bits, or the URL for download. The organization can set policies as they would for any other components.
• Facilitates shared services - In large organizations where IT is serving developers, there is a trend to transform them into a services organization, instead of an implementation one. Basically they vet and approve tools before they are used. And offer the developers a library of components. This is usually called shared services. It helps the flow for both IT and devs, but also improves the relationship between them at the same time.
• Developer request workflow - Instead of developers asking for forgiveness later, they can very easily request a components usage without a single meeting (and assuming IT and legal respond quickly). That’s the kicker. Developers will get a response without making waves, or breaking any rules.
• Dashboards - Dashboards are necessary and the OpenLogic platform has all the ones I would expect pre-built. But I am also assuming there are some customization possibilities for unique ones.
• RSS Feed - The available RSS feed of processes is really nice, but one problem is you can’t limit to exploits only. I would like to have my reader setup so that if there is anything in the list, it’s bad news.
• Great support - I had the opportunity to meet the Rogue Wave SE team, and they are awesome! This is such an important feature of any product or organization.

Things that they could do better:

• The UX overall could be a lot better. This includes look and feel. A few things that really jumped out to me were workflow processes, policy creation, and filtering. They just need to modernize the application. It has an older feel. The terminology also takes time to get used to and does not always make sense. For example, "projects", which are usually one-to-one applications, whereas I’m used to thinking in terms of applications alone.
• I’m sort of bummed that it is only targeted at enterprises with 500+ developers. But I think this is also the fault of the user base. Smaller organizations do not really care, thus not interesting for Rogue Wave. However, I do wish there was a downstream version that all organizations could leverage.
• OOTB integrations with common tools would be nice. I want to see the following integrations. Communication tools like Slack. Alerting tools like PagerDuty and VictorOps. Log Analysis tools like LogEntries, and Sumo Logic. And source repositories like GitHub. These vendors could probably build it themselves. But it would be nice if it were there already.
• Agents are one-time use. I’m not sure this is the best thing, and in my envisioned flow, it would be nice to have static agents that are registered with the system and scan on a periodic or triggered basis.
• The API is nice, but I want more. For example, I would like some of the historical and business data accessible via the API.
• Global policies can get confusing fast and local project policies are a little confusing to me. Ideally I would like to see the ability to better organize global policies so that most policies can be global rather than per project. This would avoid duplication and confusion. But I also get that in large organizations, this is a scoping and rights issue, that local project policies address.

Due to the nature of security, there are some organizational considerations that need to be made, no matter what platform you use.

• Make sure the processes, tools, and people are setup to enable full coverage. Meaning no line of code is exempt from scans. With security it is not what you get right that matters, it’s what you miss. And if you are in front of a judge you have to prove your system works. Not that you selectively or accidentally ignore some things.
• No matter how easy it is to use, you still need to plan. Organizations need to think through things like naming conventions. If you do not have a proper information architecture, and you start populating the system with data, you end up with a mess. Data that is not very useful, and cannot be fixed retroactively.
• If you have other code analysis systems they must be tied together. Disparate systems always pose a challenge to having consistency and manage the relationships between assets in each system.
• Build a plan in advance of how audits are going to work. If you have a legal team, trust me this will be done for you. But it has to be part of the on-boarding process.

In general I like OpenLogic, and I love the approach, and idea of making component security simple. Mostly because organizations in DevOps do not spend the time to do such deep security evaluation, and this could be their demise. The OpenLogic tool does the job, and is not complex to use.

My dream environment

You think the pace of a DevOps environment is scary? Well now that we have containers not only can risks be in code they can be in the containers themselves. The great thing is that with some extra work all the tasks done manually can be automated with release automation tools.

Here is how my dream environment using OpenLogic would look.

OpenLogic analysis would start at the step of continuous integration all the way through to release. I would automate the download and running of the scanners via an infrastructure scripting language like Puppet or Chef and I would do my integration builds on brand new instances of a Docker containers. I would then use testing tools via the API to identify any issues found and make sure they are addressed before delivery, where all the tests will be run a final time. Finally I would set up alerts to on-call developers. This would allow all issues to be spotted on a per commit basis, and save a ton of time without any manual efforts.

I think that 100% of organizations need this tool or one like it. I’d pitch even a small, developer-only organization to leverage such a tool in their processes. Just one issue in production could easily put them out of business.

Security may feel like doing homework or a taking pill, but it does not need to take as long.

Not only can a platform like OpenLogic save everyone's job, it can get past the IT nagging and slowness developers hate - and - IT’s fear of developer component self-service, and lack of security awareness. This will improve their relationship as well as the overall security and quality of the software being released.