As a Developer
If you are a developer,spotthevuln.com can be an invaluable resource. It will help you write more secure code that won’t have to be supported as much. Developers understand how frustrating rewriting and fixing code can be. Developers that use spotthevuln.com will limit the amount of time they spend supporting their code by writing it correctly the first time.
As a Development Manager
Development Managers understand that if developers write code correctly the first time,they won’t have to spend as much development resources rolling out code fixes. As a development manager,the authors suggest to create a small competition among your developers. One example is have your devlopers submit code fixes to you when the vulnerable code is released. This shouldn’t take more than 5-10 minutes for a junior level developer.
On Friday,review their fixes to see how they went about programming the solutions vs. how the solution was implemented. This small exercise each Monday will help your developers write more secure code in the future.
As an Instructor
One of the big flaws in teaching software development is the lack of security awareness among students. Realizing this,the authors attempted to create the site with this in mind.
As an instructor you can use spot the vuln to help aid your students in identifying security vulnerabilities.
If you plan on using samples from this blog as a part of a formal course of instruction or a teaching aid,you can count on one (1) vulnerability along with its solution to be presented every week.
Making the Most of SpotTheVuln
This blog focuses on source code analysis from a security perspective. The reader should keep in mind that writing code is only one piece of the engineering effort required to create and maintain large complex software projects. The integration of development,quality assurance,and management disciplines are essential in the smooth execution of software creation and maintenance.
Once the solution sets are posted the reader can broaden their perspective by asking themselves questions such as:
- Is the code fix implemented by the software organization a good one? Why or why not?
- Why did the organization choose to fix the vulnerability in the manner they did?
- How would you test a code base consisting of 100,000 dynamic pages for similar vulnerabilities?
- How would one test to ensure the fix is robust and comprehensive?
- What testing criteria would make a good quality gate?
- What engineering/administrative/automated gates can be created to ensure similar a vulnerably doesn’t make its way into future code check-ins?