My dear readers,
I cannot seem to get Frank Sinatra’s My way song out of my head.
Especially the opening that goes like:
“And now, the end is near
And so I face the final curtain”
Splendid voice. Meaningful words.
We are also about to draw the curtain on our Coding Guidelines adventure.
I hope you have enjoyed the experience so far and that, at least for some of you, the information provided was useful and helpful.
Let us get into the last post before I get too emotional 🙁 .
Today we will discuss some security aspects of webMethods development and review the existing code review tools.
Non-code review tools which I consider helpful will be also mentioned.
To clear up the expectations from the start, I will NOT be talking in this chapter about security mechanisms that you can use for your application.
These are usually dictated and enforced by the company’s Security Architecture team as a part of the overall architecture strategy.
So I will not be talking about: basic auth, SAML, OAuth, certificates, etc.
These are large subjects by themselves and if there is the need, they will have their own post(s).
Rather I would like to talk about what you can do at a low level to make your code more secure.
Avoid code duplication
When you think of code duplication, you usually do not consider this a security problem, but a maintenance issue.
However, duplicating code might impact security in a negative way.
Usually, the code is not treated consistently when duplicated meaning that changes may not be applied to all copies.
The risk that you make security enhancements in one part of the code, but forget to add them to all the copies is rather high.
If you acquire a resource (file descriptor, stream, etc.) somewhere within the code, make sure you release it.
Take care that the code that releases the resource always gets executed.
The last thing you want is to have the release code present but not executed at runtime.
Not releasing your resources makes attacks of type Denial of Service and Resource Exhaustion much more effective.
Hardcode sensitive information – NO!
Like the code duplication topic, also this one has (at least) 2 facets:
From the maintainability point of view, let’s assume that you have some sort of hardcoded information in the code.
When that information changes, you will have to modify the code and redeploy it.
At least in a big company, this means also some rounds of testing (including regression testing).
This all adds up to a high maintenance cost.
From the security point of view, hardcoding sensitive information (passwords, user data, IP addresses, etc.) in the code is a clear NO-NO.
If someone gets hold of the package you are deploying, they might obtain this information and use it against you. (Decompiling .class files or understanding flow.xml files is not a big deal)
I advocate on separating the code from the configuration, in the sense that the configuration should not be deployed together with the code.
Moreover, the sensitive configuration should be kept in a secure store and not be easily accessible.
The code – configuration separation principle has a positive impact on maintenance.
The Operations team can be given access to the configuration and be able to modify it without going to the development team.
Logging sensitive data – NOPE!
This is not something particular to webMethods development, but a rule that should be applied throughout the industry.
Do not log sensitive data as you do not know where the log files might end up.
This data might be (but is in no way limited to): client info, bank data, insurance details or, God forbid, password related information.
As you know most judiciary systems assume that an individual is not guilty until proven otherwise.
When programming this is the other way around: trust nobody, question everything.
In this particular case, validate your inputs.
Maliciously crafted inputs that come through service arguments may cause problems and result in data corruption or data loss.
More details on this in the 2nd part of the series, available here (Clearly define service signature section).
Tools of the trade
I have tried to pack these 6 posts with as many guidelines as possible, but without having a way to enforce them, they are of little help.
Here is where code reviews come into play. The code review is the action of verifying that one’s code is compliant with the industry or company guidelines.
Code reviews can be manual or automatic.
Manual code reviews are done by a peer or lead developer that browses the code and checks it for compliance with the rules.
I do not like manual code reviews because they:
- can eat up a lot of time especially in a fast running development environment
- are error-prone (we, as humans, are subject to making mistakes)
- usually, do not have tooling support
I like manual code reviews because they:
- are great for learning; you can learn a lot by looking at someone else’s code
- help the team stay connected to each other
Automatic, or automated, code reviews are done via specially crafted tools.
These tools go by the name of static code analyzers, code quality tools or even code inspectors and they check the code against a static set of rules.
These type of tools are a novelty for webMethods as they appeared only in the recent years.
The problem: If you are developing mostly using Integration Server, then SonarQube cannot help you.
And what is a problem, if not a wake-up call for creativity (to quote the words of Gerhard Gschwandtner)?
Following this philosophy, some automated code review tools have emerged in the last years.
Others are being developed and are now in the pipeline. Yes, pun intended 🙂 .
Let’s take a look at some of them.
Integration Server Continuous Code Review – Software AG
This tool would definitely benefit from a renaming. A more catchy name is in order.
ISCCR is developed and offered by SAG GCS (Global Consulting Services) and has some interesting features:
- command line tool to easily integrate with Jenkins
- Eclipse plugin for SAG Designer that is fairly easy to install and use
- reports generated in HTML and CSV formats
- large base of checks (naming conventions, flow services quality, etc.) already implemented + additions made every release
- extensibility, i.e other checks can be implemented and existing checks can be modified
- it provides for every check the actual technical rule (for example the query made against the flow.xml file)
- can break the build if the checks are not met
- you can enable/disable particular checks
- contains a lot of the checks mentioned in this series
- tested compatibility down to 8.2
What I dislike about it:
- licensing information is not clear (you have to contact your local GCS representative)
- provisioning with the new release of the tool is not clear
All in all, it is a good tool to have and use and has most of what I expect from it.
The extension with new checks is not so hard and requires just basic Java skills.
Sonar Flow Plugin – I8C
As mentioned here this tool was created by Stefan De Wandeleir and Samuel Vandecasteele.
I have to say that my knowledge is limited to what I have read about it because I did not install it.
This tool is actually a plugin for SonarQube as opposed to other tools that are either accessible via the IS Admin GUI or as a plugin in Designer.
- easy to understand by the developers that are already familiar with SonarQube
- extensibility: you can implement new checks
- easy setup, as explained here
- easily adding new checks (as far as I could tell from browsing the examples)
What can be improved:
- the number of checks; the documentation specifies just 9 checks
- documentation: it has to be updated with the same frequency as the code and in certain parts, it has felt behind
If you are familiar with SonarQube and want your code review results (i.e static code analysis results) to be there, give this tool a try.
You can always extend it to fit your needs as long as you respect the license.
This tool – Advanced webMethods Developer
This tool intrigues me.
On the one hand, you have a documentation that lists the capabilities, has nice screenshots, etc…
On the other hand, there is absolutely no information about the tool itself: download link, how to install, etc…
So, basically, I have no idea what to think of it. Is it for real? Or is it just another item in someone’s closet of broken dreams?
If you have info on this, please drop me a comment or an email.
If you know others tools or are involved in developing new ones let me know and I will check them out.
Also, it would be a great reference for anyone reading this post.
The following tools are not code review tools, but I consider them useful.
I will write some words on each tool and you can check them further on their sites.
Spoiler alert: I am a fan of Atlassian products, so if I am a little bit biased, please forgive me.
What I like at these products (besides functionality and usefulness) is also the fact that they have catchy names.
Hear that SAG with your Integration Server Continuous Code Review?
And no, Atlassian is not paying me a dime for these words 🙂 .
Crucible – Atlassian
This tool helps you in the manual code reviews allowing the developer to create code review requests for the work that was done.
The reviewer gets notified of the existing request, can open it, perform the actual review and indicate the changes that need to be done.
The tool is collaborative and allows the developers to discuss regarding a certain code review.
You can easily keep track of what was reviewed and what not thus eliminating double work on the reviewer’s side.
One of the unsung benefits of this tool is the “getting management off your back” feature.
This means that now you actually have a list of code reviews and their status to show to your boss.
Fisheye – Atlassian
This little tool works best when used in combination with Crucible.
If Crucible lets you manage your manual code reviews, Fisheye lets you easily visualize the code you are reviewing.
You have a diff tool, a code search option, and an activity stream.
Now 2 points are worth mentioning here:
- the majority of Fisheye’s features got incorporated into other products
- that diff option will not help you that much with Flow services as it cannot visually represent them
But, Atlassian says that their products are easily extensible.
So, if you want, go ahead and build a Flow visualizer plugin/app for Fisheye.
JMeter – Apache
You might remember me from the previous posts saying again and again: “Do your load tests”.
Well, now I am letting you know what I use.
JMeter is easy to learn and lets you load test pretty much whatever you need.
I have mostly used it for load testing SOAP Web Services, but it can help you with a large number of applications, servers or protocols.
If you are a fan of the good old Swing look and feel (click on the above picture to see it in all its splendor), JMeter is the way to go.
And just as Michael Jackson said: “This is it!“. We have reached the very end of the Coding Guidelines series.
Before we go let’s do a recap of what we covered:
Part 6 (this one) – Security basic guidelines and useful tools
It’s been a fun ride.
As always, until next time…..
P.S.: Are you tired of not knowing when my next post is going to come out?
No worries! Hit the Sign Me Up! button and you will receive my posts as soon as they are published.
Do you think my ideas would benefit someone you know? Share it! Spread the word! Sharing is caring 🙂