Continuous Deployment is an time-saving, team-loving, kudos-earning, stress-reducing capability that any team is wise to implement. OnCheckin is definitely aiming to bring this awesome’ness to as many ASP.Net developers as possible by making it fast and easy to setup. Once you’ve started out automating deployment though iteration is the key. Deploying your website early and often is great but with OnCheckin this goes further – Add-ons. And where better to start than helping developers out than with an often overlooked part of web development: Application Security.
It was nearly a month ago that OnCheckin launched to bring easy to use Cloud Powered Continuous Deployment to all ASP.net developers. Since then we’ve deployed 800 websites built by developers from 42 different countries an average of 10 times each.
The feedback and input has been great and there’s some great new features in the pipeline to make the service even better.
This weeks feature set is just the start.
Security is not a Feature
While building OnCheckin I’ve worked really hard to ensure that all of our users’ information is kept safe and secure away from prying eyes.
Website application security is an incredibly important part of any website’s development cycle.
A common misconception is that applications are best secured after they are developed.
The last task before deployment into production.
Modifying your application to take into account the findings of a security audit after you are finished building typically results in a large number of security flaws and a lot of changes. Some of these flaws might even involve serious architectural issues at the core of your application.
In a best case scenario, development teams can look forward to spending a large amount of time and effort fixing these flaws.
Worst case, the application may require reworking large parts of the codebase and an overhaul of its architecture –potentially affecting any project timelines.
This can be incredibly expensive and time consuming.
Does this Sound familiar?
That’s because web application security is just like integration and deployment: something that if left till the end of a project, time/money/development team member’s sanity can be affected.
If you integrate security into every stage of your development lifecycle (just like deployment), you not only build more secure applications, but save lots of un-needed UAT/Security testing anxiety.
This is a clear sign that a more strategic approach needs to be used to avoid an endless security bug-fix cycle.
Security on every Build
Starting today OnCheckin comes with two new important security features. One to cover you before every deployment, and one to test your site after deployment.
To see these results all you need to do is take a look at the two new tabs in any deployment project’s build results screen:
Web.config security scans
A lot of vulnerabilities in ASP.net websites are simply through misconfiguration – usually in your web.config. OnCheckin now scans the web.config in every deployment job (even ones that fail or don’t finish), for over 30 different vulnerabilities that misconfiguring your site may open up.
These range from simple common mistakes like leaving debug mode or tracing turned on through to more subtle things like the misconfiguration of cookies.
We’ve started out by using the totally awesome Web.config Security Analyser built by Mesut Timur as a base and building upon it to offer a more updated 2013 view on web.config security issues. The great thing about using open source software is that any new functionality added to WCSA will be given back to Metus and the community through some friendly source control commits.
To use this feature, simply do a deployment of any of your OnCheckin projects and on the result view for your project you’ll see a list of anything our service has picked up under a new Web.config security scan tab:
This allows you to make any modifications required to lock down your project’s configuration from day one on every build and deploy.
ASafaWeb post-deployment testing
If web.config security scans take care of your application’s miss-configuration, our partnership with Troy Hunt’s service ASafaWeb works you covered in production by scanning your website once each deployment is finished by talking directly to the real deal: your deployed website.
To turn this feature on you simply need to turn on post deployment website testing in your project’s configuration.
You do this by going in to edit your deployment project’s configuration, choosing the Review tab.
Then selecting the Enable switch next to the option Test Website after deployment? This will show you a text box where you can enter your website address.
Click on the Test button to make sure that OnCheckin can access your website.
And then check the checkbox next to "Run Asafaweb security scan after deployment”.
NOTE
ASafaWeb has a good little test URL that you can use to test against your project:http://notasafaweb.apphb.com
Once you’ve done this, after every deployment we’ll talk to ASafaWeb and get any results from a scan of your website.
These are available under the ASafaWeb tab in your project’s build results page:
Just the start of things to come
This is the first round of new features added to OnCheckin since launch and it definitely won’t be the last. I’m really keen to hear what your thoughts are on this and anything else you think would add value to your website’s continuous deployment pipeline.
As always you can keep track of and vote on new functionality on our public Trello board or get in contact on twitter @OnCheckinApp or email support@oncheckin.com.