AskAppSec - Capturing Flags

Deliberate practice proved being invaluable in my own career. The last months showed me once again that this applies to the field of security just as well.

As we can't practice security related skills on just any system without causing harm, we need dedicated spaces to practice safely. Fortunately, there are lots of options readily available out there, way too many to list them all. Hence, here are just a few sites that provide not only great starting points yet also the opportunity to go as deep as you can.

• OWASP Juice Shop: This is an intentionally vulnerable web app, mimicking a quite common e-commerce scenario. Based on this, you get a set of challenges presented that allow you to try out techniques to find and exploit the present vulnerabilities. It's been my own entry point into practice apps for security and the gamification behind this app in particular really drew me in further.
• OWASP WebGoat: Another commonly cited OWASP project that offers you a place to practice. In this case, you go through dedicated lessons to learn about vulnerabilities, to see how they work and how they can be mitigated.
• Hack The Box: This service offers you a huge amount of prepared virtual machines aka "boxes" to practice on safely. I really like their starting point machines that guide you towards the secret aka flag you're trying to find and introduce you to commonly used tools to identify and exploit vulnerabilities.
• TryHackMe: Another service offering lots and lots of machines to practice on. You have plenty of themed learning paths to learn on with a lot of detailed information to guide you on the way. Both Hack The Box and TryHackMe have big communities active on Discord offering a great support network.
• PortSwigger's Web Security Academy: The developers of BurpSuite provide a great resource with lots of challenges to solve in order to learn more about web security in general.
• PentesterLab: The courses offered on this platform include lots of explanation and guide you step by step to learn skills needed for penetration testing. My thanks go to Yianna Paris for introducing me to this service!

Besides these dedicated apps and labs available around the clock, you can also watch out for hosted public capture the flag (CTF) events. I've recently joined one from Huntress and I see several being announced for the upcoming holiday season, like TryHackMe's Advent of Cyber or the SANS Holiday Hack Challenge. Being in security-focused communities and following more security folks on social media really helps to learn about these CTFs. Alternatively, you can check dedicated sites like CTFtime to look out for the next ones coming up.

When practicing in these kinds of spaces on such kinds of challenges, I've experienced the following benefits.

• Reduce scariness. Dipping your toes into security can by scary indeed. You might not know where to even start, so having these kinds of practice spaces can serve as just the starting point you need. More often than not, they include challenges designed for beginners that offer further explanation and guidance to get you introduced into the space.
• Grow knowledge. Through these practice apps I usually got introduced to something I didn't know before, be it a concept, a tool, or anything. For example, they also provide a great reason to get to know security focused Unix systems like Kali Linux, Parrot Security or Mobexler and their respective tool boxes.
• Hone skills. The more we practice, the better our skills get, and the more we can make connections between things we know. More pieces to complete the puzzle, or in our case the next challenge. Creative problem solving is definitely a skill we're practicing here!
• Build confidence. The more touchpoints we get and the more we seize practice opportunities, the more we can grow our own confidence that we can also figure out the next challenge.
• Spread awareness. We can use the gained knowledge and skills to raise awareness about vulnerabilities with others. Even better, by practicing together we can increase awareness in real time. These kinds of challenges can help people see what's possible and why we need to defend our systems, protect value and keep harm away.
• Find joy. Security can be perceived as such a dour and tedious topic. Finding solutions to security challenges, however, can feel very rewarding in itself. Doing challenges together can further help with connecting security with fun and make it more interesting for people to engage with. It can also help to find community and like-minded people to learn and grow with.

All of these advantages I've experienced myself as I've been trying out various vulnerable apps, a bunch of labs offering dedicated challenges, as well as dipping my toes into my first public CTFs. I've also seen them over and over again with conference participants, joining me for many sessions of "capturing flags together" at SoCraTes, FroGS Conf and Agile Testing Days. It's been just the same when hosting practice sessions with colleagues in the past - something I'd like to pick up again in coordination with our current InfoSec team.

So, just practicing within these spaces gives us everything we need, right? Well, unfortunately that sounds too good to be true. There are also downsides to these kinds of challenges. Kudos to Dave van Stein for making me think more about this!

• Artificial challenges. All these spaces are crafted with a specific goal in mind, usually to educate and provide a safe place to practice. Therefore, challenges are inherently artificial and can't fully represent real-life scenarios.
• Mindsets differ. Attackers tend to think differently. I mean, they usually don't have the one clear flag to find in a constrained environment to announce their win. Instead, they might gather all kinds of information over a period of time, and based on that build their strategy on whether to exploit identified paths into a system, what to gain from it, and so on. It highly depends on their motivation and goals as well.
• Uncertainty instead of solutions. For labs and CTFs you'll know when you made the right move, you get a reward. In real life, there's no cheat sheet, there's no walkthrough. Just potential and ambiguity and never being completely sure that whatever you've found (if you've found any at all) is all there is to find.
• Overly focused on penetration testing. All the sites listed above are mainly offered to practice penetration testing. It's the one hot topic that probably attracts most people, but how often do you actually need those skills? How many jobs are in this area compared to all the others? There are so many more skills needed in the field of security. So where are the challenges on secure coding, or secret storing, or vulnerability evaluation, or threat identification, or incident response, and so on? Well, more practice apps are being built all the time, so some of these do exist already while not always being in the spotlight. And of course, there's official formal training to have as well (though it can come at high costs).

Weighing benefits and downsides against each other, I consider deliberate practice opportunities like the ones listed above still invaluable. We do have to be cautious, though, to put them into perspective and be clear about their goals and limitations.

That leaves me with yet another question: can we practice closer to reality? Here are a few approaches I think we could experiment with. I'd be happy to hear about further options to add to the list.

• Replay past real incidents. I'm thinking of actual security issues that your own company faced. We could replay these very real scenarios both from an attacker and a defender point of view and hence learn what we can do better - very concretely for our specific situation.
• Run open thinking exercises. Deliberately practice approaches like threat modelling, attack trees and similar to improve our thinking, within our actual work context to make it as applicable as possible.
• Host custom-tailored CTFs. Have one person hide a custom flag on your own system for people to find. It might still be an artificial scenario, yet placed in your very real context. This requires quite some preparation of course, like a dedicated environment to practice on and, as usual, explicit consent from all involved parties. The gained insights might still be worth the effort.

Personally, I'm sure I'll continue making good use of the various practice opportunities there are. I'm also considering joining or starting a CTF team to make practice even more deliberate. If anyone's interested or has recommendations for good places to find a welcoming, inclusive and diverse team please let me know.

Now let's bring this question back to the community: what do you do to practice your security skills?

Agile Testing Days 2023 - Celebrating Opportunities

It's been the 15th edition of Agile Testing Days and the conference came a long way. This was my very first conference in 2015 and I was fortunate to be able to come back every year since then - never regretted it! On the one hand, there's the huge and diverse program to choose from, and on the other hand, there's this wonderful and ever-growing community to come back to. Loved meeting so many awesome folks again, while I missed opportunity to check in with others - it's a lot going on, I hope next year we can make more space for it. At the same time, I got to know lots of people I haven't met yet! This is something I'm looking out for deliberately, and while I didn't have much capacity this year to go mingle proactively, I'm glad it still happened.

Sunday

After attending so many editions of the Agile Testing Days, returning to the venue felt like coming home in all the best ways. There are usually some familiar faces to instantly meet in the lobby on arrival, and there are lots of people to re-connect with during the evening before the event starts.

A few of the people I could already catch up with were Elizabeth Zagroba, Joep Schuurkes and João Proença, having a lovely dinner together and exchanging what happened since we last met. I really enjoy these kinds of shared moments at conferences. Besides the official program, these opportunities are usually the most insightful for me.

The evening faded out at the hotel bar, meeting more awesome people again like Udita Sharma, Shivani Gaba, Dragan Spiridonov, Richard Bradshaw, and so many more. It was also the first opportunity to finally meet people I only knew from social media like Yuya Kazama, as well as make new connections like with Nadja Schulz.

Monday

The first day of the event is dedicated to full-day tutorials, the official conference opening and dinner in the evening. Personally, I really like kicking off the conference with attending a tutorial. On the one hand, I enjoy the focus time on one topic before the huge, busy program starts, and on the other hand, I really like starting with a smaller group of people and get to know them better before a whole lot more join during the regular conference days. This time, I had the pleasure of having Sanne Visser right next to me in the tutorial - loved it. Over lunch, I could also re-connect with Jumpei Ito and get to know Masanori Kawarada. The day was already off to a good start for the conference!

• Tutorial Breaking into AI and Machine Learning by Tariq King. I hesitated for quite some time to dive further into machine learning. Yes, I've attended a few talks and workshops in the past years on the topic, yet haven't tried much of the generative tools or LLMs yet. Therefore, this tutorial was clearly one to learn from. Also, I've had a few chances to join Tariq's tutorial at other conferences yet always went for a different topic. So, it was about time to finally get out of my comfort zone and seize this opportunity. Didn't regret it one bit! It was a great dive into different areas of AI and machine learning. I especially appreciated the hands-on experience we could gain, and then learning about theory as we went - instead of the other way around. It made this topic really accessible, and you could see how you could apply this in other areas as well. Definitely recommended.
• Keynote My tale of playing the Testing Game by Maaike Brinkhof. This keynote was an awesome opening for the conference - a pity not everybody was there yet, this would have deserved the big audience. I love it when people share their story, what decisions they made, what they learned, where they struggled. Really related to the options provided in the end as well - we should be intentional about our moves; we don't have to just stay where we are and be miserable.
  
• Mini-missions: making the everyday exciting by Veerle Verhagen. Somehow I missed that there was yet another talk scheduled before the evening started, so this was a nice surprise! Unfortunately, I didn't take a sketchnote of this one, yet I really liked the idea Veerle presented. Going on mini missions (or side quests) to get your mind set on something else when everything is otherwise too much, you're getting anxious, you're lacking drive, or anything else. No actual tasks you have to accomplish, yet fun little optional things that can help you enjoy life more. It was amazing to see how this idea really stuck with people throughout the conference, looking for mini missions throughout and having fun with them - what an impact!

The evening started with speakers dinner as well as greet and meet dinners for participants to break the ice and get to know a few people already. This is a really good opportunity for everyone already around. The event can be overwhelming as it is, and it's good to have some familiar faces in the crowd you can more easily catch up with. That's one of the huge advantages of being a speaker returning to an event you've already spoken at, as you usually have made lots of connections already through speaking.

When it comes to speakers dinner, Agile Testing Days is known for treating their speakers very well! That includes food and drinks, the scenery, basically the whole atmosphere. It's been yet another amazing evening together with lots and lots of awesome conversations. Catching up with Micha Kutz and Vernon Richards. An amazing opportunity to reconnect with my dear friend Thierry de Pauw! Together, we had really insightful conversations with João Proença and Johannes Nicolai about branching strategies and pull requests with all the trouble and benefits that can come from it - loved it.

Tuesday

The first regular conference day started with all its usual busyness, lots of people, lots of learning. Here are the sessions I joined on that day.

• Tuesday Morning Lean Coffee by Janet Gregory and Lisa Crispin. I just love lean coffee sessions for all the serendipitous insights and inspiration! Janet and Lisa are great at setting a welcoming space for them. This time, I learned about maturity maps - Wardley mapping applied to teams. We also once again talked about adapting our wording for desired impact; for example, does it help more to talk about a "test strategy" or a "delivery strategy" in the given context?
• Keynote 10x Software Testing by Kristel Kruustuk. Kristel painted a picture how testing evolved over time, and how AI and machine learning helped her company become more effective. She also made clear that big changes don't happen over night, yet usually in taking many small steps.
  
• The alliance of a security engineer and a tester by Aleksandra Kornecka. I really liked that this talk spread awareness on collaboration and career options in security! Personally, I've seen testing and quality overlap with security work quite a few times, and vice versa. Joining forces resonated a lot with me, as well as her point that cybersecurity is everyone's job.
  
• Facilitating a quality process assessment by Janet Gregory. As I've done a few assessments myself in the past for my own as well as other teams, I really related to this talk. Janet presented steps to facilitate an assessment and gave lots of advice what to look out for. For example, watching for gaps between what people say and what they do - so much this!
  
• Keynote Could Agile Testers Help Debug Management? by John Buck. John shared how common organizational structures result in autocracies, especially on the top. These usually lack the feedback loops that are crucial to have good product outcomes. He presented a different option in the form of a sociocracy with elected representatives and various forms of consensual collaboration. Including debugging the system and finding better approaches instead.
  
• Workshop Collect your explorer badge by Udita Sharma and me. This was the first time we could give our brand-new workshop together! We presented a new approach to help with exploratory testing: applying high concepts from the domain of fiction to the world of exploration. What for? To come up with exploration ideas ourselves, to explain what we do to others, and to inspire more folks to join us in these efforts. All in very short time, without unfamiliar jargon to make it accessible for everyone. It's been a great experience to prepare and facilitate this workshop together with Udita, and we just loved seeing people engage so much with our content.
  
• Keynote Missed Opportunities. When quality is put in a box. by Erika Chestnut. I really liked Erika's take on opportunities, especially those that we miss, be it intentionally or unintentionally. For ourselves personally, in our careers, as well as for our product. "Poor quality is a succession of missed opportunities" - I so much relate to this! Erika also encouraged people not to stop with testing, yet look for further opportunities to influence quality.
  

That wasn't it yet for the evening! First, there was the snack exchange, initiated by Sophie Küster (who unfortunately didn't make it in the event, and who was missed dearly!), and organized by Tobias Geyer. Lots of folks from the community brought regional snacks they love and it all came together in huge snack piles on the tables. So many wonderful tastes to explore! Just awesome. Some might say it maybe wasn't the very best idea to do this right before the big dinner, but hey, we all still enjoyed both very much - and it's unicorn land after all, so who is anyone to judge?

Dinner and party for everyone is on the usual program for this evening. A costume party to be precise! I personally really dislike dressing up, yet this is my favorite costume party ever. I've not been judged by not dressing up once, and everyone just enjoys whatever they want to wear and whatever everyone else came up with. This year, the theme was 90s, so it was a real throwback time into me teenage years for me. Loved it. Also, lovely food, a huge 15th anniversary cake, and great conversations. 

Usually, this is also the time organizers reveal who won the Most Influential Agile Testing Professional Person (MIATPP) award. This year was special though. It was officially the last in-person conference for Janet Gregory. Phew, what a tough, sad moment for all of us to say goodbye to such a huge and dearly loved figure in the community. At the same time, what a happy moment for Janet to move on to new endeavors and opportunities! All the feelings. Janet and everything she's done for this community was celebrated - so very well deserved. I owe a lot to her and can only hope to pay it forward in some ways. I'm very happy I had the opportunity to be there to witness her goodbye, and I'll keep her in my heart and memory.

The evening was long and awesome. There was finally time to catch up with my dear friend and learning partner Toyer Mamoojee. Time to talk with my amazing colleague Rita Avota who volunteered at the event. Janina Nemec and I could finally play SET together, an opportunity we waited for since SoCraTes. A chance to re-connect with Marianne Duijst and her family! Really loved seeing my friends Anne Colder and Vincent Wijnen again. The evening got longer and longer, lots of folks, I just loved it.

Wednesday

The longer the previous evening got, the more tired I was when getting up on this day. Well, there's always a trade-off, and I realized the fear of missing out and the enjoyment of the moment didn't let me take care of myself as much as I should have. Not sleeping enough took a toll on me. Still, I tried to make the best out of what the day had to offer.

• Keynote Reimagining Automation by Andrew Knight. He presented an interesting narrative of the past and future of testing, showing what could be. I especially liked the emphasis of automation as tool beyond testing, which we already see nowadays. Lots of food for thought how we would like to create our future, and for which cases tools will be able to assist us best.
  
• Workshop The Hitchhiker's Guide to mobile accessibility by Nithin SS. This was a really great session that would have deserved more time, as there are so many aspects for mobile accessibility to consider. I gained lots of insights and resources from the session and loved the hands-on exercises. A lot to take with me and digest further.
• Keynote Everyone is a Leader by Zuzi Sochova. Lots of gems in this talk! I really liked the message of everybody being a leader and being able to influence - more people need to hear this. Same applies to what true collaboration really means.
  
• Workshop How to Untangle Your Spaghetti Test Code by Michael Kutz and Christian Baumann. Loved this session! Very relevant and very hands-on. Micha and Chris shared lots of tangible advice how to recognize issues in our code base and what helps to remedy them. My table formed an awesome ensemble to work together on the exercises provided, which allowed us to contribute from our different perspectives and learn from each other. It's been a real pleasure to work again with Mazin Inaad this way!
  
• Keynote MOVE THAT WALL by Dr. Rochelle Carr. I've seen her keynote at Agile Testing Days USA this year, a talk that really hit home for me. And once again, this was yet another powerful and energetic presentation. I saw and heard from many folks how impactful it was for them, and you could also hear it in the many, very personal questions asked right after the keynote. I especially appreciated the very direct and clear advice provided that makes you think. In the end, if there's a wall in front of you, no matter what or who it is - let's move it!
  
• Keynote Don’t go breaking my code by Lena Nyström and Samuel Nitsche. Now this was something completely different! I knew these two were up for something, and yet they exceeded my expectations. A different kind of keynote to be sure! Who can claim they've seen conference speakers act and sing on stage, in a musical-like way, while also conveying great points probably lots of people can relate to? Very entertaining, something to remember. I especially loved the message that we need each other to deliver something of value, so let's build on that together.
  

In the evening, I felt really tired and was ready to take a break from the crowd. That was when I met Parveen Khan again, and we decided to go out for dinner that night! Loved that calm time to catch up. Afterwards, I had energy again to mingle and have the evening fade out in good company.

Thursday

While Agile Testing Days usually starts slow with the whole week and plenty of time lying ahead, it often quite quickly comes around to the last day of the conference. Here's what I chose to close things off.

• Keynote A Fighting Chance - Learning the Art of Conflict Resolution by Alex Schladebeck. This keynote was meant to be given by both Alex and Sophie Küster together. Although Sophie unfortunately couldn't make it, Alex did a great job keeping Sophie in this talk and in people's heads nonetheless. The keynote provided lots of valuable and tangible advice on how to deal with conflict situations. I especially loved the concrete statements provided that we could use in our communication with each other, as this is what I often struggle with.
  
• Workshop Ensemble Testing by Elizabeth Zagroba, Joep Schuurkes and me. Time for my second workshop! Again, I was in lovely company. Elizabeth, Joep and I had lots of fun setting the space for effective collaboration and fun learning to happen. We introduced people to working as an ensemble (also known as software teaming, formerly referred to as mob programming). We offered three different topics for people to choose from: exploration, programming, and security. I had really fun with the latter, facilitating yet another "capture the flag together" ensemble session! People really engaged and, judging from the feedback received, seemed to have a good time while gaining lots of insights. Just loved seeing this!
  
• Keynote Wait! That’s Not Tested by Heather Reid. I really like Heather's stories and all the data she gathers to tell them. This keynote was full of great points as well. I especially loved shifting the narrative towards thinking in bets and hence minimum shippable risk - phew, some real food for thought to take with us!
  
• Continuous performance testing with K6 by Alexander Chumakin. Alexander presented a distinct set of tools and demonstrated how they can work nicely together. Really concise talk, giving a concrete example of how we can improve performance testing.
  
• The paradoxical state of performance testing by Sonja Nesic and Frank Kootte. Sonja and Frank shared their story of where they came from and what they did to turn the ship around when it comes to performance testing. Lots of tangible advice. Especially applying lessons learned from functional testing to performance was great food for thought! 
  
• Keynote The Rise of Generative AI: Judgment Day by Tariq King. And here it was, the closing keynote of the conference. Tariq shed a light on generative AI from the angle of the Turing test. He also did a live imitation game with us, presenting us with artwork and music that may or may not be real. That was a quite impressive demonstration that drove the point home how easy we are to trick! While there's no real intelligence yet for machines, we should consider revising the Turing test. In any case, we're overdue in coming up with an ethics framework around these kinds of tools to use them for good rather than bad purposes.
  

With that, it was a wrap. The 15th edition of Agile Testing Days was officially over. Lots of people still stayed around and engaged in the various evening activities. As it became a tradition, I went out for dinner with a lovely group of people.

As always, we still ended up in the hotel lobby. Playing another round of games. Using the opportunity to catch up with people we couldn't talk with yet. I really appreciated the time I had with Gitte Klitgaard this evening. Also, last minute opportunities to meet new people like Virginia Weidhaas and Nicole van der Hoeven. So many more good memories to take home with me.

I loved that this year a whole bunch of people from my code reading club were there and we even managed to make photos with (most of) each other! Huge shoutout to Anne Colder, Janina Nemec, Lisa Crispin, Samuel Nitsche, Vernon Richards - while missing everyone else being on the club.

Change Is Coming

This year was amazing, next year will be different. Well, Agile Testing Days is slightly different every year, they do a great job listening to feedback and adapting. Yet for 2024, the organizers already announced that the concept will change. I'm really curious what they are up to. They have my full trust. I will be back in any case.

AskAppSec - Dependency Updates

When one of my former managers commented on my blog post on Painless Usable Security, asking about our approach of keeping dependencies up to date, I realized that there's more to the topic and I should write a separate post about it. So here it is!

Keeping dependencies up to date has been a big topic in lots of the teams I've been part of. When I created our AppSec strategy for my current team beginning of the year, this topic once again stood out to me as the first one to tackle. This is based on our context. We have a whole bunch of services we own and most of them are around for quite a long time (and still valuable). We inherited a system that had degraded over time, and knowledge had been lost. Over the last two years, we learned to understand this system a lot better, as a whole team. We invested in several endeavors to get it in shape again, to preserve its value, and also ease extendibility.

Before going into details, let's first take a few steps back.

Why even have dependencies in the first place? Nowadays, most software is not built in an echo-chamber. It'll be based on lots and lots of other software that lots and lots of other people provided, so that we all can achieve more with less. There are specific contexts where dependencies will indeed be very constrained, usually in situations where stakes are very high. Yet even then you probably don't invent your own programming language, operating system or infrastructure. For the kinds of products that I've worked on so far, the system will have lots of dependencies to third-party frameworks, libraries, and more.

So, we need dependencies. Yet why should we update them and keep them updated? Can't we just keep everything as it is?

• Even if we don't change anything on our side, the world around us does not stop. Tech evolves every day. If we don't change anything, our system will naturally degrade from both business value and security perspective. More vulnerabilities in the dependency versions used will be found, and the system will be more and more at risk. Until suddenly it's very time-critical to have that risk mitigated. Remember Log4Shell, anyone?
• Besides security fixes, you'll also want to use new capabilities that dependencies offer in their newer versions. These can help preserve or even increase the value of your system and keeping it relevant to users, business and other stakeholders.

Fine. Yet why do people struggle so much with updates? Just do it, right?

• Dependency updates oftentimes come with the need to adapt your system to the new version. Sometimes that means completely re-architecting your solution; very painful. Sometimes dependencies had removed or replaced features in their newer versions, and you'll need to cater for that. Even if there's no obvious need to adapt the system, updates might break functionality in lots of surprising ways - so you better have suitable measures in place to mitigate that risk and detect regressions early.
• Updates can come in very fast, sometimes multiple times a day. Think about the JavaScript ecosystem for example. It can be overwhelming and feeling like a Sisyphean task: as soon as you got your system in an up-to-date state, there's a new version of at least one dependency released again!
• Dependencies have dependencies themselves. Oh my. Updating one dependency often means it's not compatible anymore with the rest, so you need to update a whole bunch of others as well; especially when updating frameworks. This also means, by the way, that dependencies have to keep on top of their own dependency updates. The struggle is real.
• Dependencies might be discontinued and not get any updates any longer due to a variety of reasons. They might get moved to other places, integrated into other projects, you name it. Sometimes you can migrate, sometimes you have to find similar tools from scratch again to meet your needs. For any newly introduced dependency, it needs evaluation and validation again (better do it regularly for existing ones as well). Licenses are crucial to consider, especially when including open source dependencies. Checking its usage, how many people contribute to the project, how many issues had been already identified or fixed, when the dependency was last updated, how much community support it has, and so on. It's good to have a guideline in your context what's considered suitable to choose and what not, and what's the reasoning behind it.
• You have more dependencies than you might think. The number of libraries directly used by your services alone is probably high. Yet there's also the infrastructure you're running on and its dependencies, like container images with their operating systems and - surprise - their respective dependencies. There are dependencies to data storage solutions and so on. It's a lot to keep up to date.
• Probably the biggest hurdle I've seen is getting buy-in to do this kind of maintenance "keep the light on" work as part of normal everyday business. It's an investment and there's opportunity cost - if you invest in one thing, you can't do another at the same time. This often leads to not investing in maintenance at all. A strategy which comes around to you soon enough, presenting you with even bigger investment needs to get back on track again, while already being hindered to follow other opportunities that you wanted to prioritize for business reasons. It can slow you down to a complete halt. Yet as that's usually only a future problem of a potential risk, it's really tempting for people to ignore it (guilty of that myself). It requires lots of experience, discipline, and good practices to still keep your system tidy and in shape, continuously. And keeping each other accountable, we're fallible human beings.
• Last but not least, context is crucial. In industrial cybersecurity settings, updates might have a hugely different impact, not only financially yet also when it comes to safety. Lesley Carhart describes it well in her CyberWork podcast episode. Context really matters, risks can differ heavily.

What about tools to help us keep dependencies in shape?

• There are Software Composition Analysis (SCA) tools to help you detect outdated dependencies, including their known vulnerabilities. They usually compare your dependencies' versions against a list of available versions and reported issues for each. Integrating tools into your source code hosting platform and delivery pipeline can help as well. You might have heard of OWASP Dependency-Check, Dependabot, Renovate, Snyk Open Source, and the like.
• Package managers often come with integrated checkers. Like NPMs dependency-check which also offers to update potentially straightforward ones automatically for you.
• Modern IDEs support you by indicating outdated or vulnerable dependencies, like IntelliJ IDEA Ultimate does. Check out Marit van Dijk's awesome talk Keep your dependencies in check to see it demonstrated along with lots of useful advice.
• There are repositories like Maven Central to get dependencies from in all available versions, which often also help if dependencies moved their artifacts, got renamed, deprecated and more.
• Tools like OpenCVE allow you to subscribe to updates for your technology stack to get alerts on potentially relevant security issues.
• Sometimes frameworks offer migration tools to help with bigger updates.
• More and more people talk about software bill of materials (SBOM) to keep inventory of all kinds of software including dependencies in use.

Lots of aspects come into play when updating dependencies, and there are probably a lot more factors to consider than listed here. The big question to answer is what's most helpful in your context to actually get the job done, get the dependencies updated and keep them updated.

Let's talk about strategies. How can we keep dependencies updated?

In a previous team, we worked with major updates once per quarter, going through everything. This worked okayish for the given context of an internal product with limited usage. In my current team's context, however, we have a customer-facing product with a hugely different attack surface. So far, the following worked for us to update our services' dependencies.

1. Establish, encourage and ensure 20% time for every team member and use it to drive tech initiatives. Like getting dependencies of our services in shape. Having dedicated time to improve certain areas like this was a massive cultural foundation for lots of good stuff happening.
2. Use tooling to support easier updates where feasible. Automated scanners to indicate outdated dependencies, utility tools to adapt required related documentation for compliance reasons, and automated checks to discover potential regressions. Tools like these were great in combination with our system knowledge, so we could quickly unveil more surprises where automation reached its limits.
3. Do the easiest, most straightforward, quick win updates first and get them out of the way. It'll reduce cognitive load and clear up headspace for the bigger challenges, like the ones requiring updates of several dependencies or even frameworks. The advice to "solve the smallest problems first" helped me massively with legacy systems like ours; as far as I remember the credit goes to Nat Bennett, yet I can't find the source anymore (if anyone does, let me know). Having said that, it doesn't mean you shouldn't prioritize updating your most critically vulnerable dependencies first. 
4. Small changes done frequently compound. The system will get better step by step, you'll get better at updating the system step by step. Always a bit better. It might not look like much today, yet a month from here it's already painting a different picture. We'll get there.
5. Build on existing energies and practices. This is one of my tools that helped me with lots of culture change initiatives. We also used this to keep dependencies in shape. We have regular tasks needed for each release, and updating dependencies simply became one of them.

All this, however, likely only worked due to the team culture we fostered where people are sharing everything; knowledge, skills, load, a common goal, and more. This made it clear from the start that keeping dependencies up to date is a team task as well and we're all responsible for it, together. I hope to share more once we've lived this approach for a longer time. I'm myself curious if we can manage to keep our system in shape this way or what other approaches will turn out to be more successful in the end.

A word of caution when it comes to tooling. Scanners are only as good as the team can respond and act on their results. The cry for more tools to make a problem go away, or the desire to just finding the one right tool to save us all is not going to fix the underlying issue. Just throwing more tools on a problem won't move anything towards better - most likely, the opposite will occur. All of this becomes noise. It's overwhelming. There's so much other work to do as well. People start shutting themselves off and ignoring alerts just in order to be able to deliver anything (most likely the thing that others put them under pressure for). Yes, alert fatigue is very real. We see the same overwhelm with observability tools, monitoring alerts, test findings, static analysis feedback, and more. Having yet another class of alerts you don't get time for to understand and fix just does not help get into a better place. Not to forget false positives! Alerts that are simply not alerting you on anything real or actionable or relevant for your context are like poison.

At BSides Munich 2023, Jasmin Mair talked about "My CI/CD pipeline contains all security tools available! Now what...?" (check out the recording, too). I loved the strategy she presented to add one tool at a time, train developers, set a baseline, and manage findings. Like eliminating one class of vulnerabilities at a time, and allowing people to follow. For the case of dependency updates, we decided to go service by service, starting with the most critical ones first, and only afterwards include more tools where needed. First make alerts be seen and worth responding to again. Once we live that, we can always improve further. By the way, that was also our approach to clean up other alerts, errors, log spam, and similar noise - enabling ourselves to see what's actually important again when it occurs.

Here's another side note. Getting things back in shape wasn't done with updating dependencies. It also included other topics like removing unused code. It's always been a struggle to clean up functionality that had been superseded by something better, was just not invested in anymore, or had never been used at all while being dragged along. In one of my previous teams, we decided to get rid of all that under one big theme that also could be sold to business easier: reducing complexity. It's also part of opportunity cost to keep maintaining things that are simply not worth it any more (if they ever were). We can't foretell the future and hence need space to try things out in our product to learn what actually solves the problems our users and business have. Yet if we want to make progress towards a shared goal, we do need to make clear decisions what to keep and what not, and follow through. When I joined my current team with our big legacy system, I was stunned how much unused code was still around from many years ago. This year, we finally had buy-in to clean up - oh how much I loved it! Not only did it indeed reduce complexity and increase maintainability, made things a lot clearer for new teammates, and so on - it also reduced our attack surface! A win on all sides.

A similar case can be made for services and features we want to keep, yet that are complex, hard to understand, inconvenient to modify, or people are afraid to touch them. Not a great starting point when things go awry and a security incident comes in. Actually, if any incident occurs. Even if nothing bad happens in that area, this part will tend to stay untouched until no one in the team knows about it anymore and it's even costlier and scarier to touch it.

All in all, when I came across the following statement in Tanya Janca's book "Alice and Bob Learn Application Security", it made so much sense to me: "technical debt is security debt". Big aha moment, this resonated heavily with me. Good for maintenance and extendibility can be really good for security, enabling us to adapt fast to an ever-changing world.

It's time to bring that original question back to the community: What do you do to make keeping dependencies up to date work?

AskAppSec - BSides Munich 2023

When I started out my AskAppSec challenge, I've asked around for recommendations on communities and conferences in the security space. Jay Harris encouraged me to look for a local BSides event as in his experience these were usually friendly, welcoming and a great opportunity to network. Now that I've attended my first one with BSides Munich, I can only confirm that impression! Just loved it.

Workshop Day

The advantage of local events is that no travel is required. The downside, however, that you have to commute to get there in the first place. This turned out quite tedious with public transport and its quirks, construction works, emergencies, and so on. Additionally, getting up very early compared to my usual working days meant I was already tired on arrival. And I was nervous! As with any new conference I'm at, I never know what awaits me and how I'll deal with that. It got better over time as I've been to tons of conferences. And yet, the anxious excitement keeps coming back, especially if I don't know anyone from the community yet who could offer a safe space. This time I got lucky as Claudius Link was coming. We met at SoCraTes, even gave sessions together this year, and we've just started planning an initiative for next year (stay tuned). In any case, it's really helpful to have a familiar face in the crowd!

On arriving, registration was smooth without any hassle, organizers and volunteers friendly and helpful, and I was positively surprised about the welcoming breakfast offered. In general, food was excellent and plenty throughout the day, including a variety to choose from for people having different needs and preferences. This makes an event already more inclusive and it's a detail I do pay attention to in order to gauge the overall spirit and atmosphere.

This first day was dedicated to workshops only. I noticed how few people were around. The workshop tickets were gone very quickly, yet there was lots of space. Super sad to see, especially considering the whole event being free. People reserving tickets yet not showing up meant they took away the opportunity from others who would have participated. Kudos to organizers who reminded folks frequently upfront to kindly give tickets back when realizing they couldn't come.

There were plenty of workshops to choose from, covering lots of interesting topics. For me, Claudia Ully's full-day workshop "The Hitchhacker's Guide to the Mobile Galaxy" was a clear winner as I want to dive deeper into mobile security and I can use the gained knowledge at work. I was not disappointed at all, this workshop was amazing! I loved how smooth the setup was, especially given that mobile has lots of requirements. It was awesome that while there is quite some theory needed to get everybody on a shared page to start from, the focus was on hands-on exercises. Claudia encouraged us to join forces, help each other and ask questions, which really made this a safe space to learn. The content was structured in a way that made it very accessible for people not having experience in the mobile space yet, while also providing lots of technical details valuable for people who came with prior knowledge. We went from mobile history and basics to Android specifics, static analysis, reverse engineering, to a discourse on iOS, to hooking into things with Frida and objection. And all that in the theme of Douglas Adam's "The Hitchhiker's Guide to the Galaxy"! Claudia even had a "42 - Don't Panic" towel with her, how cool is that? If you ever have the chance to catch one of her workshops, do it - fully recommended.

After such a full day of learning, I was pretty tired - and yet didn't want to miss the chance of socializing. Hence, I joined Claudius and a friend of his for drinks to conclude the day in great company.

Conference Day

The second day came, the main part of the conference with a program full of talks. And a whole lot more people! Same here, registration was quick, organization smooth, food was plenty and the venue a great choice, too. Lots of friendly and helpful organizers and volunteers around, and amazing speakers with a variety of topics to learn from.

The program consisted of two tracks which presented a difficult choice. Here's an overview of the talks I've picked.

• Keynote "The Seven Sins. And Virtues. Of IT Security. And how they affect our world." by Mario Heiderich. The conference theme was all around the 7 SYNs. What would the seven sins look like in cybersecurity, and what about the seven virtues? Mario's conclusion resonated with me: we cannot jump to the ideal state, yet we can take small steps and continue to learn.
  
• "(In)direct Syscalls: A journey from high to low" by Daniel Feichter. This talk dove right into the technicalities of Windows system calls and how red teamers can make use of them to bypass system controls. Packed full of details for a complex topic, this talk could only scratch the surface given the limited time. Daniel encouraged everyone to try it out and consume further material on the topic.
  
• "SOC Analyst’s Arsenal: Essential Tools, Tips and Tricks for Effective Investigations" by Samuel Kavaler. A talk full of hands-on advice and tool recommendations for the everyday work of a SOC Analyst. For people in different roles like me, it's been also interesting to learn which kinds of tools are used and for what reasons.
  
• "Bio-Lock The future and ethics around DNA Cryptography" by Tayla Sellschop. Cryptography is a whole topic in itself, yet what if we bring DNA into play? It offers a large storage space, while also not requiring as much computing power and hence power consumption, so it could become a sustainable solution in the future. On the other hand, there are a bunch of problems attached to using your own personal DNA - how would we feel about data breaches then? Yet as Tayla demonstrated, our DNA is already everywhere!
  
• "Secure containers - Do component reduction strategies fix your container security nightmares?" by Michael Wager and Michael Helwig. Really interesting overview of how we could tackle container security by using "distroless" images, only containing the application and its runtime dependencies without any other operating system programs. They are a lot more secure and less open to vulnerabilities, so why not make them the new default? At the same time, they also have disadvantages that might make them less attractive in their current state. Interesting topic to look into further.
  
• "Christmas Hancitor Campaign" by Artem Artemov. Loved this talk showcasing how proactive identification of threat actors and their victims can help prevent impact. Great storytelling of the investigation of a curious case and the actions taken to reveal more information until the puzzle pieces finally fell into their places and harm could be prevented. Incident response does not always have to happen in hindsight, it can start way earlier!
  
• "What We’ve Learned from Exposing Atlassian on the Internet: In-Depth Analysis from an Offensive Perspective" by Oleksandr Kazymyrov. A great story of "what would happen if..." and what you can learn from it to improve a system. Relevant for everyone having services publicly exposed to the internet behind SSO. Loved the testing mindset of always going a step further to identify what else can be accessed publicly and misused in an impactful way.
  
• "DevSecOps culture" by Ali Yazdani. This talk resonated a lot with me, from misconceptions shared to the cultural mindset shift required - I've seen this over and over again when working in testing and quality! Especially loved the emphasis on easing clear communication across roles as well as solving a problem together hands-on, no matter your role.
  
• "My CI/CD pipeline contains all security tools available! Now what...?" by Jasmin Mair. Another awesome talk where I just kept nodding! How many times have I heard some variation of "let's add some more tools" to solve a problem or satisfy a demand. Yet without the respective culture change nothing is solved just by having more tools. People need to learn the tooling, understand findings and figure out how to work towards a better outcome. Jasmin encouraged everyone to see it from a developer's perspective, being overwhelmed with hundreds of tools, each with their own interface and quirks, with every tool adding complexity and pain points. She made clear that proper tool evaluation and adoption is an investment and will take time, yet it's worth it.
  
• Keynote "Security by design" by Ana Oprea. The closing keynote draw a full circle to the opening one, also referring to the conference theme of 7 SYNS and how we can foster the virtues. Ana drew a connection between security and reliability and how designing for one of those aspects can help the other one and vice versa. I also liked that Ana emphasized risk assessment considerations and recommended techniques like threat modelling. She reminded us that people won't always realize they are a target or underestimate adversaries and their driving motivations.
  

By the way, slides can already be found on the website, and talk recordings will be published soon.

As I was taking sketchnotes, my biggest challenge was to switch rooms as there were often no breaks scheduled in between talks. It somehow worked out yet was more stressful than I hoped for, and it was strange to leave during questions, missing the answers. On the other hand, the breaks that had been scheduled worked out nicely. The program offered quick ones sufficient for bio breaks, and longer ones to digest what we've heard, refuel with nourishment, and connect with people.

The folks I talked with were really friendly and welcoming. Special thanks to Ben Wandel, Claudius Link, Sebastian Porst and Sergio A. Figueroa for our great lunch table! In general, I didn't notice much condescending behavior or being frowned upon due to aspects like my role or gender. I observed quite some diversity with this regard among the participants. Representation was even higher among the organizer and volunteer group, and it nicely showed in the conference concept and program.

Conclusion

This conference is driven by community and you can feel it. It was organized with care, ran smoothly, people appreciated the offer and seemed to have a good time. All this provided as a free event. Kudos to organizers and volunteers, thanks to sponsors for making this possible! 

I went home with my mind being full of all the things I've learned, my soul with all the new connections I've made, and my heart with the feeling that this is yet another place and community for me to become truly part of and belong to.

This definitely won't be my last BSides Munich and BSides event in general, I'm already looking forward to future ones. So, my first security conference was awesome - what are your recommendations for the next?

---

UPDATE: Fahri Korkmaz also wrote a blog post about BSides Munich. He shared lots of notes of talks I didn't attend, plus a lot more details on talks I did. Really worth checking it out and diving in deeper!

AskAppSec - Security Champions

The first time I heard about security champions programs was from Tanya Janca and the idea stuck with me ever since. If you haven't come across this concept yet, here are a few good resources on it.

• Building Security Champions by Tanya Janca
• Security Champions (OWASP)
• Security champions series by Snyk
• The Security Champion Framework by Chris Romeo, Izar Tarandach and Brook Schoenfield
• The Security Champions Podcast: Tanya Janca - A Recipe for Security Champions

For the first time, I'm in a company that not only has established a security champions program, it's also the first time I became a champion myself! Therefore, the topic grew even more relevant for me in the past months.

Recently, I came across several rather negative, or let's say frustrated viewpoints on security champions programs. People I met said it just never worked for them. Some shared they were not having real organizational buy-in and the program was merely a point on a checklist to tick off for the company to look good. Chris Romeo shared lots of security champion antipatterns in his Reasonable AppSec newsletter that made me think. "Why Security Champions Are Not the Silver Bullet" by Matthias Rohr is another thought-provoking piece pointing out that other initiatives might work better in certain contexts. What I don't hear much about in my bubble, though, are success stories from security champions programs. I do remember one person at Booster Conf talking about their program that managed to raise awareness and spread knowledge. Yet that's... basically it.

It's my first experience with such a program and I only see its current state after having run for quite some time. Therefore, I can't really tell how effective our program is and if it improved the situation compared to the one beforehand. From what I've observed, it does indeed seem to work quite well so far. It did manage to bring people together and scale the efforts of our InfoSec folks through having invested volunteers as contact persons and security advocates in each product development team, hence building bridges. There's clear guidance for lots of security topics and good practices. In the teams we have on demand support and feedback from InfoSec at any point from idea to production. At least from my personal perspective, collaboration works really well. We have buy-in and time set aside for security topics and can actively help drive security efforts for our products and the company. Huge shout-out to our awesome InfoSec folks at this point!

That being said, we recently also talked about how our program can be evolved. The conversation was initiated by an InfoSec person sharing Snyk's Security Champion Playbook and asking people for improvement ideas we could try. I did share my personal point of view of what I'm missing or what would help me benefit from the program even more. We're all working remotely and as of now asynchronously as security champions. It's not a secret how much I am a fan of synchronous collaboration, so that's what I would wish for more. Be it in the sense of regular calls with champions and InfoSec, or frequent pairing and ensembling sessions to work hands-on together. This could be on specific learning topics, general fun challenges like Capture the Flag (CTFs) sessions, on our regular security related tasks, or on solving current challenges in the teams - together. Joining the regular InfoSec call where folks exchange current news would be a great addition as well. 

We haven't decided yet what exactly to try out next. I'm curious what other ideas people have, what worked for them best so far and what not at all. More real experiences that we can all draw inspiration from. So, let me ask you: what makes security champions programs effective?

AskAppSec - Painless Usable Security

Imagine security being painless, easily usable and just the usual way we do things. Imagine this for both those who develop products and those who use these products. Wouldn't that be amazing? My optimism tells me it's possible, and yet we're often far from it.

In one way or another, I kept thinking about this for the last months. At SoCraTes and FroGS conf, I've facilitated sessions on the topic. We gathered lots of insights together with participants, hearing what struggles they faced and what opportunities they found. What we can do to change the narrative. Many thanks to everyone who contributed! Here are the points that came up repeatedly when asked what's painful.

• Fear. It's scary to ask questions, especially about security. Security teams (if you even have them) might be very detached from teams' everyday realities and not approachable, might even be condescending, or just wave around a policy without being helpful. There's a lot of secrecy and gatekeeping going on as well. And what if we make a mistake and people blame us? What if I see something yet have every incentive encouraging me to look the other way instead of reporting it?
• Fatigue. So many alerts, we're overwhelmed already. So many false positives reported by tools, which makes it even easier to ignore yet another scanner result and just bypass it so we can move forward, as we're pressured to do. Security theater is huge at play here as well, everyone talking how important security is without ever seeing real actions taken. Why not just tick those boxes in the easiest way so we can say we comply without actually fulfilling the spirit behind regulations.
• Future. Well, security is indeed a future problem, isn't it? Yeah, that risk exists, yet will it really ever happen? We'll rather cross the bridge when we come to it. We have so many other things to do after all. And as we can't invest in prevention now, let's put security last by default. Hence, we can ignore issues we see, as no real pain is perceived - until suddenly the pain is super high.
• Friction. I know this is the more secure way, yet I have to jump through ten hoops, get approval from hundred people and then sign this contract with my blood - or... I just do this one-liner change. Procedural problems are real. Poor experience is real. Difficult cross-team collaboration and dependencies are real. And they have very real impact on behavior. If something is way too much effort for what it's worth, we're usually not going this extra mile (or at least aren't rewarded for it).
• Futility. Security is just such a huge area, security work is never finished, we'll never know everything. The system is so complex. We lack knowledge and we have so much else to know already. We struggle to see the actual impact of vulnerabilities anyways. We can only know the system is insecure, not the other way around. All this feels really futile, so why invest at all.

This list resonates with me a lot, and I see these points in my own work context as well. Especially when there's a whole backlog of things that we know we need to improve, yet struggle with balancing competing priorities. Fatigue is a real challenge indeed, like fatigue of pointing out problems and proposing solutions that just don't cut the list of most valuable things to do right now.

I've also talked with several people in the communities I'm in, where security was sometimes perceived as painful due to other reasons. Like, why is security the only quality aspect that is considered and gets buy-in, what about all the other ways in which we can harm our users, our own people, our product and company? Why do we get external experts for security yet not for other topics (like accessibility)? Why do security policies just always make things harder? What is it that security slows us down while not achieving actually more secure outcomes?

Finally, there's the angle from friends and family not working in tech. Security? Well, that's often perceived as the thing that annoys you, that you skip. Oh my, another update, why do people have to change things all the time. Oh no, another factor to log in, why does everybody need to do this nowadays. My goodness, another popup to click away so I can do my job and go on with my life. I heard a lot of statements like this, usually accompanied with frustration and anger. Or with shrugging things off. I don't care if they have my data, what would they do with it anyways. Yeah, I know this company has proven to do bad things and yet they offer the best usable solution compared to more secure competitors.

So how can we reduce the pain and friction, increase usability and make security the easy route to take? In all my conversations, the following points came up repeatedly.

• Ease development experience. Anything that makes security easier and reduces friction and cognitive load from the start can help. Include thinking exercises like having evil personas you could use for user stories, and doing threat modelling to raise awareness before designing and building solutions. Provide good code examples. Have secure defaults, in frameworks, infrastructure, your own product. Keep things in shape and up to date. Enable folks to deliver fast and well, so we can respond fast and well to new threats. Planning for mistakes (that will inevitably happen) and recovery, and foster a culture where postmortems are considered an invaluable learning opportunity.
• Collaborate with security experts early on. No ivory towers, no jargon being thrown around. Instead, security folks being approachable and helpful, enabling team after team, pairing and ensembling hands-on. Security champion programs that actually build bridges and help scale good practices. Do this early on and continuously to make use of the best leverage. Then consider getting external persons to point out problems and receive advice, be it in the form of consultants, audits, bug bounty programs, or coordinated disclosure. 
• Be clear about risks to help prioritization. Not only do we need to assess risks, risks can also have vastly different impact depending on our specific context. Terrible consequences in one might be reasonably ignorable in another context. Learning what's most relevant in yours, and probing the risk appetite of the organization helps figure out priorities.

One thing that stuck with me is what both security and UX folks repeat over and over: security that's not usable is not security. Just as Jared Spool points out, "If it’s not usable, it’s not secure." Because people simply won't do it or find their way around. They have a task to accomplish, a goal to achieve, a job to do. If security blocks them instead of supports them, it might as well not be there in the first place.

• Insecure & Unintuitive: How We Need to Fix the UX of Security by Jared Spool
• Secure Design Concepts w/ Tanya Janca
• Security and usability: you CAN have it all!
• How good UX leads to great security by Josh Ben-David

The same applies to development teams. If practices leading to more security aren't usable, or don't fit in our everyday lives, they simply won't happen. We have to find ways to make it the easy and frictionless route, anything else is simply not sustainable.

This whole topic reminds me again of testing and quality, as so many things do in security. It's a lot about culture, it's a lot about advocacy and change. In the end it's about people. I'm wondering now: the team transformation tactics I found to help move towards holistic testing and quality, could I try them out for moving towards painless usable security as well? I probably should give it a try. Now that I'm thinking about it, I realize I literally just did apply them the last weeks. And before as well.

Let me give an example. One of our current focus topics is keeping our dependencies up to date. Updating them is one part, yet having a team reliably keep doing so is a whole different story. What I did was building on existing energies; in this case, building on existing practices that already worked for the team. And just last week for the first time it worked out well enough. People felt responsible and updated dependencies on their own without my nudging. It was clear, it was easy, it was part of everyday work. It didn't cause friction. Okay granted, I'll have to observe and evaluate this experiment further, yet on first glance it does look like less friction than before.

When it comes to security improvements for our product, I believe we need to work a lot more and a lot closer with UX folks and product designers. This expertise is invaluable and yet too often underrated. The resources listed above give lots of pointers why.

That leaves me wondering: why not also work together with UX and design to find more painless, usable, secure ways to build more painless, usable, secure solutions? There's a lot more for me to think about and try out.

I'm sure people made their own experience with this intersection of security and usability as well as respective pain points, be it for their team, organization, product or just generally in life. Therefore, let me ask you all: what's your approach to move towards painless, usable security?

---

UPDATE: This post didn't receive much response from the community yet. Really appreciated this person taking the time to share their thoughts and experiences!