\chapter{Introduction}

As the world is being completely engulfed by software, the need for accessible, but
high quality learning materials on software engineering and especially secure software
engineering is on the rise.
While we are enjoying the comfort that information technology provides us, we often forget
about the risks involved in relying so much on software in our everyday lives.
When taking a look on recent events, such as a cyber arms race taking place between leading
powers, 50 million Facebook accounts being breached
due to the incorrect handling of access tokens, or how China is building an Orwellian state 
of total digital surveillance it becomes clear that security and privacy in the IT sector
is more important now than ever.

With all of our data slowly crawling towards the cloud and an IoT revolution on our necks,
we as an industry must face the music and start actually doing something before we enter
a new age of digital wild west.
Unless we want to disconnect all our devices from all networks and ban USB sticks, the best
lines of defense are going to be people -- a new generation of \emph{security conscious} users and
developers.

The goal of Avatao as a company is to help software developers in building a \emph{culture} of
security amongst themselves, with the vision that if the world is going to be taken over by
software no matter what, that software might as well be \emph{secure software}.
Unless we want to run around in vulnerable self driving cars while exposing all our sensitive
data through our ill-protected smart phones that is.
To achieve this goal we have been working on an online e-learning platform with hundreds\
\footnote{654 exercises as of today, to be exact}
of hands-on learning exercises to help students and professionals
master IT security, collaborating with
universities around the world and providing a solution for companies in building
\emph{security consciousness} amongst their developer teams.

Since starting out we have amassed some experience in building fun challenges and tutorials
that showcase the exploitation and fixing of relevant security vulnerabilites in code or
configuration.
Traditionally these exercises revolved around offensive and defensive tasks, with challenges
often being split into two or more parts.
For example users would have to hack a website by exploiting a buffer overflow vulnerability,
then in the second challenge they would fix the code they've just exploited in a web based
code editor.
These kind of exercises offer great flexibility to reflect real world security issues, as in
more complex challenges users might be required to exploit multiple vulnerabilites for success,
and understand the ways they augment each other.
We often recreate real world scenarios based on incident reports released by companies for
added authenticity and relevance \cite{AkosFacebook}.
Our challenges usually involve some sort of website acting as frontend for the vulnerable
application, or require the user to connect to a server using SSH.

While working as a content creator I have stumbled into the idea of automating the completion
of challenges for QA\footnote{Quality assurrance} and demo purposes\
\footnote{I used to record short videos or GIFs to showcase my content to management}.
In a certain scenario I was required to integrate a web based terminal emulator in a
frontend application to improve user experience by making it possible to use a terminal
right on the website rather than having to connect through SSH.
After I got this working I was looking into writing hacky bash scripts to automate the steps
required to complete the challenge in order to make it easier for me to record the solution,
as I have often found myself recording over and over for a demo without any mistakes.
During the time I was playing around with this idea, researching possible solutions I've found
a hidden gem of a project on GitHub called \emph{demo-magic}\
\footnote{\href{https://github.com/paxtonhare/demo-magic}{https://github.com/paxtonhare/demo-magic}},
which is esentially a bash script that simulates someone typing into a terminal and executing
commands.
I have created a fork of the project and integrated it into my challenge.
Soon after recording demo videos was not even necessary anymore, as I have started to distribute
the solution script with the challenge code itself, making it toggleable using build-time
variables.

I was quite pleased with myself, no longer having to do the busywork of recording videos,
but what I did not know was that I have accidentally
did something far more than a hacky bash script solving my challenges, as this little script
was the basis of the idea for the project we call \emph{Tutorial Framework} or just \emph{TFW}.
