Becoming Rugged

Incorporating application security into the software lifecycle can be difficult; it’s not something that’s taught in schools, at least not as part of a standard CS curriculum.  Often it appears to be something that comes after software is developed, as if security were a testing, rather than development, issue.

The recently announced Rugged Software Manifesto (RSM) is aimed at making security a cornerstone of software development.  Taking a form similar to the Agile Manifesto, the RSM lays out some key points which are meant to be easily understood and improve adoption of secure coding practices.

Some points are a bit on the cheesy side (“…and I choose to be rugged“), but for the most part, each point is a straightforward statement about how software will function in the real world.  For example:

I recognize that software has become a foundation of our modern world.

…and…

Reloading Java Class Files

The good folks over at Zero Turnaround have been posting a series of articles on their blog lately that show step-by-step how Java virtual machines, and application servers that use them, reload Java class files to make the development process go more smoothly.

Their five-part series starts here, with an overview of how Objects, Classes, and ClassLoaders work.  I think it’s a clean, clear description of a process that most of us take for granted unless it gives us problems, and I recommend you take a look at their series to learn a little more about how things work under the covers in Java environments.

Links:

Part One:  http://www.zeroturnaround.com/blog/reloading-objects-classes-classloaders/

Part Two: http://www.zeroturnaround.com/blog/rjc201/

Part Three: http://www.zeroturnaround.com/blog/rjc301/

Part Four: http://www.zeroturnaround.com/blog/reloading_java_classes_401_hotswap_jrebel/

…Part Five isn’t posted yet, but when it is it will be on the Zero Turnaround Blog.

Balancing Old and New

Our code base has been around for a long time, and I’ve been working with it for almost as long as it has been around.

Over the last decade I have seen the company grow, specs appear and either disappear or become fundamental building blocks, and our suite of products — and therefore our code base — swell to a respectable size.

It is always a challenge to organically grow a company, and growing an engineering department is no different. Every couple of years a fresh set of ideas and concepts sneaks in via new hires (and hopefully old-timers!) and we take a new look at how the application is architected and maintained.

Google’s MVP Tutorial

Google has created a very nice tutorial outlining how to use the MVP pattern for building enterprise applications.

They cite two reasons for using the MVP pattern for large applications:

…we have found that a Model-view-presenter (MVP) architecture works best when developing GWT apps for two main reasons. First the MVP model, much like other design patterns, decouples development in a way that allows multiple developers to work simultaneously. Secondly, this model allows us to minimize our use of GWTTestCase and, for the bulk of our code, write lightweight (and fast) JRE tests.

While I haven’t personally gone through the tutorial myself, line-for-line, it does a good job of laying out the basic concepts of MVP, the rationale for each piece, and how they are tied together in a sample application.

This is a great compliment to Ray’s original presentation, and I think it will help move the MVP pattern along into becoming the de facto standard for architecting  large GWT applications.

Links:

The tutorial:  http://code.google.com/webtoolkit/doc/latest/tutorial/mvp-architecture.html

Wiring Up JSP-Generated Navigation Tabs With Your GWT Modules

Embedding GWT modules into an existing JSP-based web application can, as we have seen, offer the power of GWT with the depth of any legacy functionality you’ve built into your JSPs (or that you decide to run server-side in a new JSP-based application).

When we decided to use GWT, one of the things we needed was to make our GWT modules play nice with our JSP-generated navigation system.

The Role of JSPs in a GWT World

When using GWT, the default approach is to use a blank HTML page as the canvas for your GWT module.  If you are starting an application from scratch this makes sense; it lets you concentrate on one technology for the entire user interface.  For those of us with legacy applications, however, the option to mix old and new is a necessity; it also provides some potential benefits.

For starters, JSPs become servlets which run on the server side, meaning you can execute any logic you like on the server side before any data is sent to the client.

One use of this is access control; if you break your application into a number of modules and don’t want some users to have access to certain modules, it can be easy to configure a JSP  to simply not include the necessary GWT module code to the client at all.  

Checklists for Application Security

The Security Ninja has provided even more straightforward security advice for application developers: they’ve developed a security checklist that promises to make introducing good security code review practices part of the software development cycle a little easier.

You can find information on their approach here:

http://www.securityninja.co.uk/a-checklist-approach-to-security-code-reviews

GWT, Meet JSP

The vast majority of our products are written in an ancient style using Java Server Pages with our own home-grown hodgepodge (kind of) controller-like system.  There’s 10 years of user interface code written that way, which is a significant chunk of code.

Now we’re using GWT for our user interface code.  That’s great, but if you are not starting from scratch, like us, it can be difficult to figure out how to get the two technologies to work well together.

In addition, there are things that we are used to our JSPs doing for us, namely a lot of server side processing.  While you can debate the merits of too much Java code in the JSPs, the fact is that there are times when letting the server generate HTML and send it to the client web-1.0 style works quite well.

Fortunately, it is possible to have the best of both worlds.

A View Back, and Looking Forward

It’s been both challenging and rewarding publishing these Supply Chain Technology postings on a semi-regular basis, and it is difficult to believe it has already been several months since we started this endeavor.

Our traffic picked up substantially when one of our GTN-MVC posts was picked up by a GWT news aggregator, and our GWT posts remain among the most popular we’ve written.

Scientific Security

While dealing primarily with “real-world” — as opposed to software — security issues, this paper (PDF) outlines some suggestions for improving security by applying scientific principles, including those used to avoid reporting bias and issues with self-reporting.

We’ve recently gone through an upgrade of our security process, and we’ve found that when looking over all potential security issues it can be surprising to find that the issues we thought were very important to address — the issues du jour — don’t always stack up well against less interesting but more potentially severe (or pervasive) issues.

Links:

• Reference to the paper on Bruce Schneier’s Security Blog
• The paper:  “A Call for Evidence-Based Security Tools“  (PDF)