wSAST Support

My @IOActive hack::soho talk on wSAST is finally online! If static code analysis interests you then you may enjoy hearing a little about the journey, trials and tribulations of building a SAST engine from scratch! youtu.be/QEBRx42uk50?si=A-aY…

Thanks everyone who came out to @IOActive hack soho to see my talk on wSAST! I’ve put my slides online here: wsast.co.uk/ioa-hs-winter24.…

I had an idea for @wsastsupport - I might write a “parser” that allows you to specify language components in a regex form (how to extract a class name, method, statements, expressions, etc.) and have wSAST look up based on the source file extension how to do this “light” form of parsing of the source file. These could then be converted to WSIL with more or less information and analysed. Then all the regular generic rules could be run over the information as extracted (CWE, data rules for things like SQLi, etc.) as well as a new regex rule type that can “grep” the source of the specific code being analysed. This would allow a huge number of languages to be supported in a light fashion and wSAST intelligence for things like control flow analysis to be applied alongside simpler techniques such as regex. Interesting concept and all possible within the bounds of what the framework supports!

Today I am pleased to announce the release of a code analyser I’ve been working in my free time - wSAST (wsast.co.uk) wSAST aims to make code analysis easier for application security consultants by providing tools to graph relationships, find paths between functions, and identify entry points into codebases as well as perform full dataflow and static analysis using a powerful rules engine. Rules for analysis can propagate taints, express arbitrary relationships between variables, and attach arbitrary data to variables as they flow through the application during simulated execution. Rules can be written as simple XML format rules (for simpler types such as function rules, variable and type rules, and data rules), or in .NET for completely customised rules which can then be as convoluted as you like. Multiple sources can be attached to any variable and multiple sinks to any trace, which then come and go from execution scope per a specified scope anchor. Since wSAST is implemented over a custom intermediate language (WSIL) to which all supported languages are translated it will be able to support multiple languages. At the moment only Java core language support has been completed, and C support is about 95% complete but has no rules at this time. My plan for the moment is to keep the core engine closed source but make all the rules, the front end, rules engine all open source and .NET based. I plan to make further steps towards this by releasing the code for these components to the wSAST GitHub when developer guides are finished. It will be possible for developers to add custom language support (if they’re brave enough!) using the interfaces provided, and the C to WSIL translator will be open source as an example. I hope people find this useful! Don’t hesitate to contact me if you have any questions, on here or on @wsastsupport