Monthly Archives: May 2013

How to choose a software vendor

So, you’ve decided you need a software vendor to build an application for you. It might be an idea you have for a great new product, or a tool that needs to integrate with an existing system, or an application to automate a manual process in your organisation.

I assume you know a little about software but you do not have much experience in how applications are built and how software development teams operate; you would like to know how to pick a software team that will build a quality product, that will understand what you need and contribute to the success of your business.

To give you some background, I am a software engineer, have led software teams, outsourced projects to remote software teams and delivered work for remote clients. I would like to share a few ideas to help you judge if a software team is worth their weight in gold.

How well do they communicate?

You will be spending a fair bit of time with the team you pick. You’ll explain your idea to them, they’ll explain their approach to the project, It’s important that you understand each other, that you click, that you are on the same wavelength. When you explain your idea to them they should understand it and be able to contribute constructively to it. When they explain their implementation to you it should be in such a way that you can understand. Successful communication is critical to the success of your project – pick a team that you can communicate well with.

Do they understand your business domain?

It is incredibly valuable if the team that you engage with understands your business domain or the industry that you are in. Have they worked with clients in your industry before? Do they specialise in a specific domain and does it overlap with yours?

A software team that understands the context in which an application will be used, will spend less time trying to understand the problem space and more time focussing on the solution. You might have a very clear documented vision of your application but inevitably decisions need to be made during development by the development team. A software development team makes better decisions when they understand the business domain.

Do you like their existing work?

Past behaviour predicts future behaviour. You can tell a lot from a team based on work that they have delivered in the past. Most teams would be happy to share a portfolio with you of applications that they have built before.

Do they design clear and easy to understand user interfaces? Is it intuitive to use their applications? Do you get a sense that they have thought through every scenario in which the application might be used? Do they take pride in their work?

Are they willing to involve you in the process?

A good software team values continuous contribution from their client. Be wary of a team that vanishes for 3 months with your requirements with the promise that they’ll deliver the perfect product when they return.

Before any line of code is written they should involve you in their planning process or at least give you clear visibility on their planning. When development starts they should be able to show you their progress on a weekly basis and invite your feedback.

A good software team understands that requirements may change during a project and they embrace change, knowing that certain things become clearer only during development.

Do they have good software development practices?

Even if you are not very familiar with software development you can still make a judgement of a team’s engineering practices by asking a few simple questions.

Do they test their software? Good software development teams have diligent process through which they test their software. You can reasonably expect testing to be partially automated and partially manual. I would be careful if they do not do a fair bit of each. Most teams would be happy to discuss this.

Do they break their projects down into small testable chunks of work? Similar to manufacturing, it is best to break a software project into small well-defined pieces of work that can be tested from a user’s perspective. Successful teams have a well-defined process by which they define, implement and test pieces of work and measure their overall progress (protip: why can’t developers estimate time?).

Do they frequently deploy their code to a production like environment? It is important that deployment to production is part of the development process early on in the project. This eliminates surprises at the end. It is also important that this process is automated.

Do they have a process in place to deal with bugs? Teams should have a process in place through which they track, prioritise and fix bugs.

Are they familiar with software security? Good software teams consider security from early on in the development project and have checkpoints in place during the project to review security of the application.

How do they stay on top of the latest technologies? Software development is a fast changing industry. Good software teams encourage and support their developers to read, attended conferences, have side projects and experiment with new techniques.

Do they contribute to the software community? All software teams rely heavily on the wealth of knowledge that is provided by the software community. Healthy software teams give back to the community through publishing their knowledge, contributing to open source projects, speaking at conferences, etc.

What is their public reputation?

A good software team has happy clients (client testimonials), they engage in conversation in the public domain (twitter, mailing lists), they are regarded as specialists in their own domain (blogging, speaking at conferences), etc.

Wrapping it up

The above pointers are aimed to help you to judge a vendor’s maturity in few fundamental aspects of software development without having to know the industry jargon. There is more to software development that can be covered in a single blog post but hopefully the above will enable you to have a confident discussion when engaging with a software team for the first time.

About Sibert Lubbe

Siebert is a software engineer, enthusiastic about all things software related – the code, the people, the business, the processes and emerging technologies.

He is based in Melbourne, Australia currently working at Find him on Twitter as @siebertlubbe or at

Upcoming in Dradis Pro v1.7: New interface

The release of Dradis Pro is getting closer. We’re in feature freeze now, just adding the finishing touches.

The new Dradis Pro v1.7 all-in-one view

One of the things I’m more excited about is the new interface we have created:

Screenshot of the new all-in-one view

The focus is on simplifying access to the common tasks, those that you perform multiple times each day: creating Issues, adding notes, uploading attachments, etc.

The all-in-one view lets you see all your notes, issues and attachments in the same place, no need to go back and forth between the tabs.

A screenshot showing note contents, issues and attachments in one page

Conveniently import from external sources

Another area that has been simplified is the interface to import notes from external sources. The steps before:

  1. Click on “Import note…” tab
  2. Select the external source from the drop down menu
  3. Select the filter (among those provided by this particular external source)
  4. Type in the search term and hit Enter
  5. Right-click on the results grid and select Import

Screenshot of the old note importer

The steps now:

  1. Click on the “All issue” node
  2. Enter search term in the appropriate box and hit Enter
  3. Click on “Add this issue”

Screenshot f the new one-click importer

Screenshot showing the 'add this issue' detail of the new Importer

A few more screenshots (click to enlarge):

Use note templates to quickly create new issues

Detail of the Issue contents

Detail of the affected nodes and evidence for a given issue

Note how a given issue may be associated with multiple instances on a given host. For example, an Out-of-date Apache server can affect both tcp/80 and tcp/443

More information

If you are an existing Dradis Pro user, you can already take advantage of all this features without having to wait until the release of v1.7. We have also prepared a step-by-step reporting guide for you:

Reporting by host, reporting by issue

If you are not a user yet, you can read more about cutting your reporting time, putting external tools to work for you (and not against you) and delivering consistent results with our tool. Get a license and start saving yourself some time today.

VulnDB API update + new VulnDB Help site

We have improved VulnDB API and have a new (and better) Help site. Read on to find out more about these changes.

VulnDB HQ is a tool to manage your vulnerability descriptions so you can reuse them across reports. It also lets you create and share testing methodologies so every project is delivered to the same high quality standard.

The VulnDB logo

We have recently migrated the VulnDB Help site to a new location at:

Apart from the new look & feel (which we hope you like) we’ve made a few significant improvements in the API itself:

Strict SSL requirement

The API was accessible over plain-text HTTP due to a misconfiguration, we have completely disabled this.

Token-based authentication

Say your goodbyes to HTTP Basic authentication and welcome the new token-based authentication overlords.

Visit your Profile page to get your own API token which can be used to authenticate API request by means of a custom HTTP header.

A screenshot of the section of the Profile page showing the token

Lost your token or you suspect it was compromised? Want to deny access to your account to all 3rd party applications? Regenerate your token and you are good to go.

Better examples

We’ve improved the examples for each of the API methods with a proof-of-concept `curl` request along with the sample of any data that has to be submitted to the request. We also show response codes and content returned by the server so you know what to expect.

tl; dr;

Find answers to your VulnDB API questions at

Note that we have not bumped the version number to introduce these changes. This is because the main interfaces, media formats, end points and data types have not changed.

Upcoming in Dradis Pro v1.7: Issues and Evidence

A new release of Dradis Pro is in the making: Dradis Pro v1.7. We continue to evolve our solution based of the feedback we receive from our users.

Starting in Dradis Pro v1.7 we have introduced two new concepts:

  • Issues: these are findings or vulnerabilities. An example would be: “Cross-site scripting“.
  • Evidence: this is where you provide the concrete information / proof-of-concept data for a given instance of the Issue.

For example:

  • The ‘Hackme bank’ application is vulnerable to Cross-site scripting (Issue). There are 7 instances of this issue and here is the information about them (Evidence).
  • The HTTP service in tcp/443 of the host is affected by the Out-of-date Apache Tomcat issue and so is the tcp/8080 service in

As you can see, the main benefit of this approach is that you get to describe the Issue once and reuse that description.

To continue with our example, we’d have to create the following project structure:

Here we would add the Out-of-date Apache Tomcat Issue to the all issues node of the project, and then the Evidence for each host will be added in the corresponding node.

By segregating core vulnerability information from the evidence associated with each instance of the issue, we can start doing some powerful things.

Reporting by host, reporting by issue

On the one hand, some penetration testing firms like to structure their reports by finding. They go through the list of issues identified, providing description, mitigation advice, references, etc. and including all the hosts affected by the issue in each instance.


On the other hand, some prefer to structure their report by host. They list all the hosts in-scope for the engagement and describe each issue that affects them.

Of course there are others that provide these two options in the same report. A section where all the issues are described in detail followed by a host summary where you can quickly see a list of issues affecting a given host.

In order to provide this level of flexibility there needs to be a segregation between the issue details and the instance information.

With the introduction of Issues/Evidence in v1.7, we have just opened the door to all this flexibility.

More information

If you are an existing Dradis Pro user, you can already take advantage of all this features without having to wait until the release of v1.7. We have also prepared a step-by-step reporting guide for you:

Reporting by host, reporting by issue

If you are not a user yet, you can read more about cutting your reporting time, putting external tools to work for you (and not against you) and delivering consistent results with our tool. Get a license and start saving yourself some time today.