It’s been some time since I last wrote about YAWAST on here, it was actually back in April when I posted the last update – that was for the release of YAWAST v0.7.0. Currently, it’s at version 0.11.0 and a lot has changed. It’s been rewritten from scratch, more people have become involved, it has moved to a (fairly) regular release cycle, and has expanded a fair bit in terms of functionality.
This is somewhat about the changes, but it’s more about the mission of YAWAST, and what I am working to achieve.
When I last wrote here about YAWAST, it was written in Ruby, it’s now Python – it was (quite obviously) rewritten from the ground up. Made more stable, easier to extend, more flexible, and far more thorough. The reason for the rewrite was quite simple, it was a poll I posted to Twitter:
Poll: Would you be more/less likely to contribute to an open-source security tool based on the language it's written in? If so, which language would lead you to be most likely to contribute? (Please RT, trying to get a feel for what security devs prefer – Thanks!)
— Adam Caudill (@adamcaudill) May 18, 2019
What we see here is that there is actually quite a difference in the likelihood that someone would contribute to YAWAST based on what language it was written in. When I wrote the first lines of code for it back in 2013, Ruby was a favorite language among security-focused developers – most likely due to the fact that Metasploit Framework is written in Ruby. Fast forward 6 years, and Ruby received only 5.6% of the vote, while Python received a massive 55.6% of the vote.
For a tool like this to gain long-term success, it’s important that it become more than a one person show. With this in mind, I started the process of rebuilding YAWAST from scratch – this was a huge time investment, working a full-time job during the day, then working till 3AM most days on the rewrite. While that was a huge short-term investment, it was an investment in the future.
This rewrite provided an excellent opportunity to completely rethink the architecture of the tool – as it was becoming more complex, the older architecture was becoming a substantial limitation, making it difficult to achieve the level of coverage I desired. Now, it’s easy to add new checks, and add them in a far more efficient manner that what was possible in the past. The investment opened the door to making the tool far more useful, and far more effective.
When performing a penetration test1 against a web application, there are a huge number of things that a tester needs to look for – especially early on. The goal of YAWAST is to make the first hours of a penetration test as efficient as possible. There are a few ways that it works towards that:
- It checks for as many issues as possible (that are suited to automation).
- It provides both detailed output to the console, as well as a machine readable JSON file that can be used in conjunction with reporting tools to simplify the reporting process.
- Once an issue is identified, the tester no longer needs to worry about it. This allows a tester to run YAWAST at the start of a test, and within a matter of minutes, they have eliminated a number of items from their to-do list.
By eliminating as many issues as possible at the start of an engagement, it’s possible to spend more time focused on what penetration testers do best: leverage their extensive experience and knowledge to find issues that no scanner ever will. YAWAST isn’t meant to provide an assessment on it’s own – that’s simply not the goal, the goal is to allow more time and focus to be spent on manual testing (where the real value is).
I have devoted much of my career to making teams more effective, and that means identifying areas where productivity, focus, and energy are being lost, and taking advantage of technology to address those issues. I did this in development, and I do this today in application security. It’s no secret that time for a penetration testers isn’t cheap, and it should be used as efficiently as possible to produce the best possible results.
The goal of YAWAST is, simply put, to make penetration testers more efficient.
- When I use the term penetration test here, what I am actually referring to is a combination penetration test and vulnerability analysis. I am a firm believer that combining these two provides that most useful results, with the greatest long term positive impact. ↩