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?