Adam Caudill

Security Leader, Researcher, Developer, Writer, & Photographer

YAWAST: News & Mission

YAWAST Logo

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.

The Rewrite #

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:

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.

The Mission #

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.

  1. 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. ↩︎

Adam Caudill

Related Posts

  • The (Questionable) Future of YAWAST

    The last release of YAWAST was on January 1, 2020; while the release history was sometimes unpredictable, the goal was a new release each month with new features and bug fixes. I intentionally took January off from the project. In February, I left the company I was at; the team of penetration testers there had helped to inspire new features while looking for ways to make them more productive. But something else happened in February, an issue was opened – something that appeared to be simple, but in fact, made me realize that the entire project was in doubt.

  • YAWAST v0.7 Released

    It has now been over a year since the last major release of YAWAST, but today I am happy to release version 0.7, which is one of the largest changes to date. This is the result of substantial effort to ensure that YAWAST continues to be useful in the future, and add as much value as possible to those performing security testing of web applications. If you are using the Gem version, simply run gem update yawast to get the latest version.

  • YAWAST 0.5 Released

    Today, I’ve released the latest version of YAWAST, a security scanner for web applications that provides basic information about the application, and performs common checks so that you can move on to the fun part of testing more quickly. YAWAST also remains the only tool I’ve found that can perform an accurate test for SWEET32. Here is the change log for version 0.5.0: #35 – Add check for SameSite cookie attribute #53 – Added checks for .

  • Testing for SWEET32 with YAWAST

    Testing for SWEET32 isn’t simple – when the vulnerability was announced, some argued that the best solution was to assume that if a TLS server supported any of the 3DES cipher suites, consider it vulnerable. The problem is, it’s not that simple. On my employer’s corporate blog, I wrote about practical advice for dealing with SWEET32 – and pointed out that there are ways around the vulnerability, and some are quite simple.

  • Developers: Placing Trust in Strangers

    Much has been said, especially recently, about that mess of dependencies that modern applications have – and for those of us working in application security, there is good reason to be concerned about how these dependencies are being handled. While working on YAWAST, I was adding a new feature, and as a result, I needed a new dependency – ssllabs.rb. While most Ruby dependencies are delivered via Gems, ssllabs.rb is a little different – it pulls directly from Github: