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!

AskAppSec - Input Validation

Input validation is a topic that's been following me around for years. I've came across countless resources speaking about the importance of input validation, or input filtering as it's called at times. What stuck with me is the recommendation to validate any input coming from any source, no matter if we're speaking about third parties, public interfaces we offer ourselves, internal services behind a firewall or accessible only from inside a private cluster. No matter if the input comes via clients, APIs, messages, data sources, or anything else. Based on my experience of working in testing and quality focused roles for over 14 years, I couldn't agree more. All that makes a lot of sense to me. Not only from a security point of view, yet also from a holistic quality perspective as input validation can help prevent errors, improve usability, increase observability, and more.

Here are a few interesting resources speaking about input validation from a security standpoint.

• Tanya Janca's book "Alice and Bob Learn Application Security" includes a great decision tree for input validation.
• OWASP's Input Validation Cheat Sheet offers a good introduction including examples.
• Kevin Smith's post on "Sanitize Your Inputs?" includes not only advice on input validation yet also touches on other topics to consider like sanitizing and escaping outputs.
• Cenk Kalpakoğlu's post on Defensive Programming Tips-1: Bad URL Handling Patterns showcases a specific example where validation is used as general mitigation approach.

Well. Seems convincing people to validate input is also a common challenge in AppSec; it definitely is in my bubble advocating for better quality outcomes. Most frequently I've seen these discussions when working with backend for frontend (BFF) services. This architectural pattern is often applied when you develop mobile applications, yet not limited to it. It is usually found along with having a bunch of downstream services that are all tasked with different duties. The BFF acts as the main entry point or proxy for a single client (e.g., the mobile app), hence only this API is public to the outside world. Any requests are routed through the BFF to the respective downstream backend services (which are usually protected further). Doing so, the BFF orchestrates incoming requests to different services; it can take care of authentication and authorization, as well as filter and aggregate data in order to respond with the needed information.

If you'd like to learn more about BFFs and see visual or code examples, I found the following resources useful.

• Pattern: Backends For Frontends by Sam Newman
• BFF @ SoundCloud by Lukasz Plotnicki
• BFF Pattern — Dos and Don’ts by Viduni Wickramarachchi
• Backend-for-Frontend: the demo by Nicolas Fränkel
• A Deep Dive into the Back-End for Front-End Pattern by Joydip Kanjilal

What about input validation for BFFs now? What I've heard frequently from colleagues can be summarized in the following statements.

• "The BFF is just an API gateway."
• "The BFF should not contain any logic, just pass through anything it receives to the backend services and vice versa."
• "Only the downstream backend service behind the BFF should validate input as it's their responsibility, otherwise we replicate the same logic everywhere."
• "Well, it's okay for the BFF to do sanitization, yet not validation."

Here's my viewpoint, and I'm very curious to hear further opinions.

Any modular component of our system needs to sanitize and validate input coming from outside in order to prevent falling into an unknown state. This is both causing poor user experience as well as presents an attractive situation for malicious actors looking for further insights that can be used for exploits. Components include frontend clients in favor of usability, even though malicious actors can easily circumvent them. As long as there is an interface accepting data from another source, there should be validation. Under that premise, I do think that also BFFs should validate incoming data, especially from the public facing side, yet also from internal backend services or other data sources. The BFF is one of the first layers of defense we have, hence if input is validated, we leave the door less wide open. We cannot rely on underlying backend services having foreseen anything that could enter the system from the outside and having sufficient mitigations in place; especially if they are developed by other teams in other contexts who might not even realize the impact of their local decisions. Also, lots of people tend to underestimate threats coming from within the company, like malicious insiders or mere human mistakes. I do understand that it's not always pragmatic or feasible to validate input on all boundaries. Yet if we have to decide, I choose validation at trust boundaries, like between the BFF as public interface and the outside world, as a minimum.

That being said: context is crucial, as always. Maybe the policy to only validate on the most downstream service works well in your situation. Maybe this is considered way too dangerous as you might be aware that specific services are not in good shape. Or maybe your product domain's nature means you're dealing with lots of confidential, sensitive data and you are more invested in keeping people out right at the door (aka the BFF API) without letting them any farther in. As usual, it depends on the risk appetite of the company, combined with your own ethics of what potential impact and harm you deem acceptable or not.

One thing I learned over and over again in my career is that arguments might convince rationally, yet they often don't reach people in a way that they change their behavior. They usually need to experience it, and usually a few times (and I'm not excluding myself in this equation). The trouble with security and similar quality aspects: I want to prevent the experience of harmful impact as much as possible. Speaking of the topic of whether it makes sense to validate input also for BFFs. I could of course invest in exploiting lack of validation, or showcasing a close to real situation, yet it's effort that still does not easily change the narrative and then behavior. If you have any further idea or tactic for these kinds of situations, your input is appreciated.

All in all, I do have a strong opinion on this topic, yet I hold it loosely enough to allow myself to be convinced by better ones. I did find posts that support my standpoint, like "Web App Security: Understanding The Meaning Of The BFF Pattern" by Syed Wahaj - yet that might be pure confirmation bias. So, I'd sincerely love to hear your thoughts and experience about this and learn more: should BFFs validate input?

---

UPDATE: I've shared this question with the wider community and received some validating feedback. My appreciation to everyone who offered their thoughts!

Great post, Lisi, as always. And I agree, every component should do at least some minimum of input validation to protect itself and the following systems. It adds to stability, observability, user experience, and more. I need to check with my team, when I’m back.

— Patrick Prill @testpappy.bsky.social (@TestPappy) September 13, 2023

What I found especially insightful was the following input from a We Hack Purple Community member, hence sharing it further with their permission so it can help more folks besides me. I think they nailed it, so I mostly maintained the original take with slight format editing from my side.

I think the answer to "Should BFFs validate input?" really depends on what it does with the data. The BFF will need to validate some input, but not necessarily all of it.

Generally, anything that looks at the data, parses it or interprets the data in any way will have to validate input.

A BFF will likely look at the HTTP request headers, so it has to validate those. It cannot assume that the request headers will be sensible, or not malicious. It may also have to decide how to deal with duplicate request headers, etc.

But maybe the BFF does not look at the request bodies, and just passes them through to the backend.

It probably would not make sense to duplicate lots of application logic in the BFF to perform application specific input validation on data the BFF itself does not process. Unless, maybe there are very common things that may make sense for a BFF to filter out before bothering the backend with it. But that would then be a bit more like a WAF that may do some general input validation, like looking for common SQL injection patterns. And this still does not absolve the backend from its input validation responsibilities.

The backend services will always have to validate the input they are handling, but even backend services may pass some data through to other downstream backend services. The important thing is that everything that looks at the data and processes it performs validation, whether that is a web server, an API gateway, a web API, or a BFF.

My deepest thanks go out to the person who took the time and energy to elaborate on this. They made the distinction I was looking for (without knowing I was): what exactly makes sense to validate where and why, given the specific context at hand. I think this is what I struggled with myself and hence struggled to convey more clearly to colleagues. Taking this explicit distinction, I feel enabled to map it to our context to make better informed decisions, and I also feel equipped to bring more clarity to the next conversation on input validation!

As a bonus, here's one more thoughtful response allowing us to weigh further aspects against each other.

SoCraTes 2023 - A Place Where I Belong

I nearly didn't go to SoCraTes this year, the "International Conference for Software Craft and Testing". My speaking budget was already strained, my schedule overbooked, and it would have meant going on vacation time. But then the organizers reached out and offered me yet another slot on the training day this year. They were even fine with me giving a workshop I already had prepared, and I changed my mind. I seized the opportunity and went to SoCraTes on vacation. What can I say, I don't regret it one bit! Granted, I'm super tired, and at the same time I'm super happy. It was so much worth it and convinced me to reserve this time of the year for 2024 as well!

Coming Back

It's always super exciting to join a conference for the first time. The second time around, a few things are already clear - you know the venue, more people, the procedures and other things that reduce your cognitive load. Still, the second time is curious as well - how will they welcome me this time? How easily can I reconnect to where we left things last year?

The first moments are awkward for me, at any conference. At SoCraTes, this very quickly vanished into a feeling of belonging. I felt welcomed, I was included, I had a right to be there. This is the foundation for everything coming afterwards.

My first contact after seeing familiar faces at registration was a person being there for the first time, Lydia Leifels - such a pleasure right from the start! At dinner, I met dear people I already know for a while, like Tobias Göschel, Thierry de Pauw (along with their daughter), Juke Trabold, and Woody Zuill. There were so many awesome folks I got to know or meet again over the course of the conference! Like Janina Nemec, Marc Kalmes, Stefan Scheidt, Claudius Link, Lea Rosema, Waldemar Tomme, Martin Schmidt, Markus Tacker - well, the list could go on and on.

Training Day

The second edition of the training day was even better than the first one. Trainers were amazing both times, yet for this year organizers listened well to the feedback and crafted a schedule of three tracks with each session having enough time to dive into the topic and generous breaks in between. Just awesome. Here's the choice of sessions I made.

• "Enforcing Architecture Using Tests" by Javiera Laso. This was the first time I heard about ArchUnit, a library to check for conventions like file names, structure, dependencies and more.  Writing tests was quite straightforward, and I can see how these could support maintainability and reduce friction by codifying agreements.
• "Modernize CI/CD Session" by Raimo Radczewski & Chris Neuroth. Very interesting talk sharing fundamental principles for a pipeline optimized for quick feedback while going small, safe steps. They demonstrated live how fast a change can be on production. A few statements I really related to were these: "minimize the time from code written to code on mainline, deployed to real users, running in a real environment, ready to be evaluated - there is no other way to develop software sustainably", "influence the loops you can", "the moment we stop slicing we deliver slower", "skip the review, pair with someone".
• "Ensemble Exploratory Testing" by me. Fun fact, I've given this workshop now for the 10th time so it became my most repeated conference session ever so far. Good thing is, it seems it doesn't get old! This time again, people were eager to join and seemed to enjoy the learning experience (which hopefully convinced them to try new approaches back at work). Well, I had fun observing people having lots of aha moments together.
  
• "Take a mess, make a mess, fix the mess" by Aki Salmi. A very interesting session on refactoring code that's untestable and contains hidden domain concepts, code that's still valuable yet needs to be modified. How? Together, we tried an approach many of us had not seen before: not even trying to understand the code in the first place. Instead, using the IDE's automated refactoring tools to slice it up first, turning hard to test code into easy to test code. Then we can document its behavior in tests, and hence gain our safety net to make the required changes. Check it out, you can follow every small commit Aki made. Nicolas Carlo also wrote a great post on this where you can follow an example: "Another way of refactoring untested code" (by the way, his newsletter is super insightful and a clear recommendation).

After the training day ended, the main part of the conference was opened with a world café. Find a group of people you don't know, take a question as starting point, see where the conversation leads you and doodle your insights on a shared canvas. After a given time box is over, everyone find themselves new groups besides one person staying at the table and getting the newcomers on the same page. Repeat until you finished three rounds. Really nice exercise, perfect to get to know first people ahead of the main conference part and have interesting conversations emerge. One main theme we had was on people, community, culture and how that's foundational. In case you're wondering where to start, I have a resource collection on inclusion that really helped me.

That's not the end of the day, of course - SoCraTes goes all in! Everyone is at the same place, we're together the whole time, so of course there's an evening / anytime during the night / morning schedule with bonus activities suggested by anyone. Such a good thing our hotel rooms are right there to retreat and rest any time. I love how Juke as facilitator and also organizers continuously emphasized the importance of caring for your needs and taking breaks.

Having learned from last year that joining all sessions can be quickly very exhausting, I decided to use the evening time for conversations and enjoying both atmosphere and company of wonderful people.

Open Space Day 1

Days start early at SoCraTes for me being a night owl, yet it's worth it. In its core it's an unconference offering an open space for everyone to bring their topics. Things they want to share, conversations they'd like to have, apps they want to build, tools to try out, skills to practice - and also challenges they'd like to get help on. With so many different people, there's a whole range of topics offered, covering a spectrum of deep dive tech topics to humans and culture as foundation for everything. No matter if it's very personal, related with our professions, challenges in society, or all combined, everything is represented. There are also sessions like doodling together, painting your nails, talking about sheep, whatever is most valuable to people right now. Be prepared to be surprised! This format of building your own schedule together on the fly works amazingly well. It definitely worked out well for me again this year.

• "Web accessibility - building beautiful web sites that don't make you puke" by njan Völker and Lina Sievering. I had hoped to learn more about accessibility at the conference, and already the first session was right on spot! Awesome workshop focused all around motion sickness induced by websites and apps. A topic close to my heart as I'm affected myself. Njan and Lina provided mindful and enlightening exercises to convey the problem and think of more accessible options together. Thanks to them, I also learned about the European Accessibility Act becoming effective as of 28 June 2025 - which means accessibility will be enforceable in Europe which hopefully gives us more leverage for accessible solutions when making product decisions.
  
• "Capture the flag together" by me. As part of my personal AskAppSec challenge, I recently tried out further services offering hacking labs like TryHackMe and Hack The Box to practice penetration testing. The first challenges were good fun to me, so I thought why not offer a session and do it together during the open space. I was positively surprised how many people came and joined me! I opted for Hack The Box and their starting point machines. It worked super well, people were engaged, shared lots of knowledge and we captured a flag together (the second we missed only due to my VPN interfering). A very insightful experience, validating my assumption that there's interest and these could be great sessions for more people to learn about security in a fun way.
• "Security for devs (& everyone)" by Claudius Link and me. The more security sessions the better, right? So why not host another one, together with Claudius who had the same idea. We had a great conversation with people bringing up all kinds of insights and common challenges. Nothing was immediately new for me, and yet it was validating to hear experienced people share similar views.
  
• "Documentation as Code" by Markus Decke. We work together at the same company, and we are transitioning to having more and more documentation as code, so I was curious about other people's ideas, struggles and in general experiences. We talked about benefits and use cases, shared tooling options and their limitations. One of the main themes was around what problem we're trying to solve and then aim for tackling exactly that, nothing else not to document only for the sake of documentation.

What about the evening? Well, after open space is before open space! As mentioned, there's always an evening schedule people are building up. Once more, I opted for dinner, conversations and more fun time! Last year I discovered that Janina Nemec is an absolutely pro in playing Set, a card deck game I've learned to love through the testing community. At first we didn't spot any deck so decided to opt for a round of Exploding Kittens (so much fun) - and finally discovered a Set deck in the end. Well, next year we're prepared to bring our own decks. Such a good way to close the day.

Open Space Day 2

New day, new schedule. Every day starts a tiny bit later, which is still early for me. And yet it was awesome again and worth the early start.

• "Stop being a superhero!" by Janina Nemec. She did an early dry run of her upcoming talk to be presented at Agile Testing Days this year - which is your chance to catch this talk, you'll be in for a treat! Janina has vast experience of working in an ensemble full time for many years. In her talk she describes (superhero) behavioral patterns she's observed (like the architecture wise or the coding wizard - way too relatable) and the pain points that result from them (like lots of work in progress without things getting done, or the behavior not helping the team grow and work sustainably). There's a solution for this: working together as an ensemble, or team programming as she calls it - saving the world together.
• "Build a minimal showcase app" by me. I have a recurring argument around a security topic and wanted to finally start building a minimal app to demonstrate good security practices. So what could be better than get this started together right at the conference? Nonetheless, I nearly didn't dare to suggest the session. And then I thought no one shows up (I didn't realize it was break time). Until people did show up and we formed a wonderful little ensemble helping me get started on a good way. Everyone else enjoyed setting things up and realizing that we all struggle in certain areas. When doing it together, however, we usually have the missing piece of knowledge in the round to avoid friction, solve problems without frustration, learn with fun, and get to value fast. A pleasant experience, would have loved to continue together.
• "Security scanning in pipeline" by Raimo Radczewski & Chris Neuroth. Both wanted to try out security scanning tools like Trivy, Syft and Grype on a real case example and see how they work and what value they bring. A really interesting session that then also sparked a serendipitous hallway conversation on why attack trees might work better compared to threat models in order to get people to think like malicious actors and consider risk.
• "Security games" by Claudius Link. He brought a whole bunch of games to teach security in a safe space with fun. We could try out a few of them and gain experience how they could be used for educational purposes. Games like Elevation of privilege and OWASP Cornucopia, yet also [d0x3d!] and a lot more I can't remember. Now I know there are a lot more out there to try out!

This was the last day for the main part of the conference, so we closed it with a retrospective. The best part here was that it didn't merely gather feedback for organizers and Juke as facilitator, it also was  intended to provide feedback for each other as participants. Over half of my group were here for the first time, and I just loved hearing their feedback and also input to make it even better for each other.

A gratitude round followed. The challenge was to thank five people we have not thanked yet. Honestly, this experience was a bit overwhelming, in all the best ways - and more than one feedback took me by surprise. I haven't mentioned yet, this conference goes big on hand-written kudos cards you can hand out any time for anything you appreciated the other person doing. The ones I received I will keep with me for long, they present such a dear memory.

Dinner followed with more great conversations. Then further sessions were hosted (remember, the evening schedule). I had a great time joining a code kata ensemble. We did the "Vending Machine Kata" which was an insightful exercise itself, yet my main takeaways were on the collaboration part. It was fascinating to see an ensemble start off quite free style and converge to more structure like having a dedicated navigator, using a timer for rotations, having the navigator stand up to be more prominent, etc. It just worked better with folks who have never worked with each other in this way. Also, we used the fish-bowl approach to ensembling, having outside observers and always open spots to join the ensemble. This exercise made me realize once again that this approach is simply not for me, despite having super kind and safe people around me it felt exclusive. I'm very sure it's actually more inclusive for other people to opt in. For me I much prefer the "all together just one ensemble without observers" format.

Last but not least, a retro gaming session! We played the old adventure game "Zak McKracken and the Alien Mindbenders" all together on a C64 system provided by Tobias Göschel - how awesome was that?

Workshop Day

Have I said the conference is over? There's still the additional workshop day! And what better format to have than asking people to bring their topics for hands-on sessions also on this day. It's also the time of the traditional code retreat, practicing the whole day solving the same kata in various ways. Originally, I was adamant to join the code retreat again, it was simply an amazing experience last year. And then Claudius Link came and suggested the only thing that could possibly lure me away: co-facilitating a security workshop. Well, what shall I say? I couldn't resist, this fit way too perfectly to my personal AskAppSec challenge this year.

We aligned on our main thoughts of what to aim for, pitched it to a fellow participant, incorporated the feedback, and came up with a workshop on "Painless Security". We crafted the agenda shortly before and went ahead with it, playing it by ear and experience in giving workshops. Having co-hosted a session the other day helped, too. Co-facilitation worked super well together, we often thought along the same lines and built on each others ideas. People shared many painful experiences and we gathered potential things to try out and what we related with most to bring back to work. I took a lot with me myself.

During lunch time, the security theme continued for me. First thinking about security conferences and ideas to contribute to the space together with Claudius Link and Susanne Neunes. Heading back towards the conference rooms, I noticed another table where Martin Schmidt and Philipp Zug, who also both participated in our security workshop, were scheming on a new security card deck. I loved the idea and they were so kind to invite me in. Well, it seems I got myself involved in two new topics - and yet I feel these are very much worth it.

I decided to check out what other sessions might still run that I could join. First, coffee though - and that's when Matthias Klass approached me and asked whether we might have another capture the flag session together, as a couple of people expressed their interest. Well, I didn't need to check the schedule anymore, security theme it was for the whole day! Of course I'll host another capture the flag session. What can I say, it was awesome! We spent the whole time until we officially had to leave the room and head for dinner. Nearly instantly, the idea popped up whether we could ask the hotel for opening the room once more during the evening. Asking was worth it, we got the keys and went all in after dinner. Many more rounds of capturing flags followed until everyone was so tired we couldn't think anymore - while being just super happy. Some of the challenges tackled were very familiar to us and hence solved a lot faster, others required us to piece together knowledge we usually don't need. All of them were very insightful and fun. So much fun. I loved that we all worked together so effectively as a big ensemble again. I really want to do more of this.

There's a traditional count of code katas done at SoCraTes, counting each exercise by everyone. I was really moved seeing so many people join me on practicing penetration testing, staying with me for so long and sharing my enthusiasm. It felt we just established a new counter at SoCraTes next to the code kata counter: the captured flags counter, aka the number of security secrets discovered. We collectively increased it to 8 overall! 

Why again next year?

Heading home, my heart was full, my brain energized, my body tired, and me super happy. I was certain that if I have any chance to be back next year I will take it.

Besides the obvious reasons of self-selected, very insightful content and just amazingly kind and inspiring people, there's a reason that is even more important. This conference is the best I've seen so far in intentionally designing welcoming and inclusive spaces. They continue to reduce friction and make it more accessible and safer to more and more people. Literally every year. There are lots of aspects of this to be found everywhere. Not only in the code of conduct that's actually being lived and enforced, or offering all gender toilets, or giving away tickets based on a lottery to level the playing field. It's in every little detail. Less noisy applause by waving hands. Exact food labelling and plenty of options for everyone. Child care service so lots of parents could join this year. Sharing Covid tests upfront for every day and encouraging masks.

The level of diversity already achieved has a huge positive impact on the quality of conversations and insights gained. A lot to learn and take with me to do better myself.

AskAppSec - Gaining Momentum

Last time I wrote about my struggles to kick off my AskAppSec challenge. Allowing myself to go tiny steps and considering any small thing as progress, I was able to make just that - progress. Well, I've had to learn this lesson multiple times already on different topics, this is just another example. Still works all the time.

So here's what happened since my last post. The following actions helped me get out of the scary zone, slowly and steadily.

Ask More People

I reached out to more security folks like Jay Harris and Dan Billing and asked them for recommendations on online communities out there. This way, I learned about new options I had not considered yet. Even when they confirmed communities I already had on my list, it provided validation that I wasn't too far off. I also got inspired by a podcast episode where Tanya Janca emphasized the importance of joining communities and named further ones. Last but not least, I finally asked publicly for recommendations and yet again could add more to my list.

Join Further Communities

Now that I knew about more communities, I indeed joined more of them. Initially, I felt adding too many would be overwhelming, yet as my initial attempts were going slow, I changed strategy. So I joined as many communities as possible to try them out and see which ones would end up as the best suited for me. Once I started, entering new ones wasn't as scary anymore as in the very beginning. If it's scary, do it more often, right? So now I've added the following ones to the those I had joined already.

• BSides, respectively the MUC:SEC Discord as the related folks are organizing BSides Munich, which is definitely on my list to go to this year
• DEF CON Discord
• DevSecCon's DevSecOps Community Discord
• HackTheBox Discord
• Laptop Hacking Coffee Discord
• TCM Security Discord
• Threat Hunter Community Discord
• TryHackMe Discord
• TechYeet Slack
• Women of Security (WoSEC)
• Women's Society of Cyberjutsu
• Cyversity
• Any InfoSec or AppSec meetup I could find that either was local to me or offered virtual events, like the OWASP-DevSlop-Project

There are a few options on my list I haven't tried yet as they didn't feel like a good fit right now. Nonetheless, I'm still on the lookout for more online communities, so anyone having recommendations please reach out.

Collect Security Resources

I've come across quite some interesting stuff in the past years, so why not finally start a page of recommended resources dedicated to security. I felt this would be an easy quick win to make progress, it would be great to have a foundation to build on and extend with anything I'm learning now, and nice to be able to share a page with folks interested to learn more about security as well.

Feel free to check out my recommended security resources, maybe this collection already offers something of value for you.

Start AppSec Courses

I'm still reading Tanya Janca's awesome book "Alice and Bob Learn Application Security". I'm a slow reader of non-fiction books, especially if I'm not traveling. So, I thought why not also try out the courses she offers at the We Hack Purple Academy. There are a few free mini-courses available. The paid ones seem very reasonably priced, especially considering the fact that they represent exactly what I'm looking for. There's even a bundle of the four most interesting courses to me, which I'm currently on: AppSec Foundations Bundle + Secure Coding.

Prepare First Challenge

I do have a whole list of potential mobile AppSec challenge options. I still need to pick the first to tackle, write about and ask feedback for. While I have a hunch which topic it's going to be be about, I'm fine with not having made the final decision yet. Again, tiny steps, and that particular one is on my radar of things to do next - besides consuming resources and engaging with the communities I've joined.

It'll come, at the right time and pace. As long as I can build on the gained momentum, I'll be fine.

AskAppSec - On Late Beginnings, Distracting Struggles and Finding Community

The personal challenge I picked for 2023 is AskAppSec. I believe that joining and actively participating in at least one security community for a period of six months will increase my understanding of practical application security in everyday work situations. When I decided on my challenge end of last year, it felt it would be a perfect fit: scary and a worthy endeavor allowing me to grow while sharing hopefully useful content. It also fit well to what I set out to do at work, taking on more explicit advocacy for security in my team and the company.

Sounded all nice and well to me, and yet I struggled, more than I expected. I'm acutely aware that it's already the middle of the year, and where am I? Well, it's not that I didn't move at all, yet I'm clearly not where I hoped to be. I need to acknowledge it and accept just as it is in order to move on from here.

Biting Off More than I Can Chew

I've been learning in public for quite some time now, and I still enjoy when I can fully dive into a topic. This year I thought it's the time again to do just that, going full in! And then life happened. Now half the year is already over, and not so much was done yet. I'm struggling with processing this. I'm between trying to allow myself to go slower, and beating myself up that I actually didn't go slow so far but instead opted in for so many other things. Distractions. Valuable stuff, yet definitely distracting me from what I set out to do: my personal AskAppSec challenge. I've recently been at Agile Testing Days USA where Dr. Rochelle Carr dropped wisdom that heavily reminded me of my situation. In her fantastic keynote "The WHY you are", she told us to remove unneeded distractions to our own potential. Does it feed your "why"? If not, don't get off course.

So, let's face it. I took on too much this year. I declined opportunities, and yet said yes to others - including creating new conference sessions. I really forgot how time-consuming and energy-draining that is (although it can have a really nice return on investment). Plus draining life stuff happened on top of all this that also demands capacity. Work is very consuming as well, although it does give me back a lot, too.

So here am I again, trying to remove tasks from my to-do list and gain more headspace so I can do bigger things, like working on my challenge. Because I also realized, I continue doing things just because I started them once, they tend to pile up as obligations - and then I bear the pain of opportunity cost and never get to things that would grow or amuse me. 

At the same time, there are a few things I always wanted to do and be better at. Over and over in my life, I practiced them for a while and dropped them again, just to pick them up to start over again and again. Recently, I realized that I added most of these to my daily habits checklist. So I actually do work on them, even though only very little by little, yet mostly every day and I make progress. I did consider them distractions for some time, yet maybe these ones are indeed not.

Finally, I kept my public writing to a bare minimum. This blog usually helped me reflect by writing things out, like a public journal on non-confidential work and growth topics. I stopped doing so as well, only fulfilling what I had loaded on myself, like writing a blog post per on-site conference. With this one, I am again just writing down my thoughts which is more than I did the last months and it feels good.

So, here's where I am right now. This is my attempt in bringing a bit more order to the chaos of my thoughts. Maybe I am indeed slacking off on the things I care about and do too much of the other things that are rather distractions. It's time to reconsider and only keep what adds to my own why, respectively the goal I had set for myself. Gain energy, headspace, and focus on what moves me forward to get stuff done and learn from it as I go.

Starting Late in the Year

Back to my challenge. Beginning of the year I had gathered material to work with, like communities I could join, interesting resources, potential challenges, and so on. Only beginning of May, I could finally start acting on this material, though.

The last months kept me super busy as life threw me a few curveballs. Yet today I finally managed to kick off my personal challenge of 2023: #AskAppSec. It's scary and I can't wait for what I'll learn on this journey! 🤩 To read more about it: https://t.co/WI9Gfh6m12

— Lisi Hocke (@lisihocke) May 1, 2023

The first weeks went quite well. I joined a few online security communities and tried first interactions, more or less successful. I read more stuff. And yet, I still found this very hard. I thought about things I could do, and then - once again - lacked focus. Distractions came my way and I happily jumped on them. At times it helps me to find more headspace if I get things out of the way first, yet this time I instead ended up lacking energy to work on my personal challenge.

At the same time, I'm still scared of this challenge. How did I do this in the past years? I conquered my fear back then and did it anyway, so how about now? I guess the only way to do this, as last years, is go step by step and never hesitate or look back. I need to break this challenge down more clearly in my head, and then finish one step after another instead of jumping around between different tasks. Do small tangible stuff.

Whenever I leave the challenge be, it festers in my mind and gets even bigger than it is. Whenever I take a step, it becomes a step smaller and seems more doable. It becomes less scary and getting stuff done simply feels good. I guess one big issue with security is that I started this topic a few times already in the past and stopped again each time, hence I couldn't build on the momentum. Turns out,  consistency is once again crucial for me.

What Happened So Far, After All

My first goal was to join communities and find a new additional place for me to learn and share. I focused mostly on online places as I don't have capacity left for on-site events this year, and didn't want to rely on local meetups only. The three communities I joined so far are the following.

• We Hack Purple. This community is initiated by Tanya Janca. I benefitted a lot from her content over the years and this community felt like a great fit to start. I actually already had joined back in 2021, yet then neglected it. This place had been quite welcoming so far, yet I feel I joined at a moment where there was not too much activity going on - I see it increasing these days. My first attempts to connect didn't receive too much response, yet it's still a promising community to be in and learn with.
• OWASP Slack. Well, OWASP continues to be the one constant we keep hearing about again and again. It's a frequently used reference point when it comes to all things application security. Everybody I talked with who had joined local chapters mentioned that the community culture differed heavily depending on the chapter. So I decided to join the global Slack first, which is quite active. Also here, I had first interactions, nothing groundbreaking yet.
• InfoSec Community Discord. A colleague brought my attention to this one. It's not been overly active these months and it felt the hardest to join in so far based on its structure and engagement. It's still good to be there and see what's going on and being shared.

I have a whole list of other communities I could join. In the beginning, I wanted to start with only a handful not to overwhelm myself, yet now I'm considering adding more. I'm especially interested in places people can recommend, so I started asking around for personal experiences.

I dived into further resources as well, which had been quite insightful so far. For example, I finally started reading Tanya's book "Alice and Bob Learn Application Security". It's really awesome and I can already recommend it. Tanya manages to explain security concepts in a comprehensible, digestible and engaging way. Theory, examples, stories, and actionable exercises - all included. For me it's perfect to see what I already know and what not yet, and for which concepts I had a grasp yet lacked the official term for.

At work, mobile application security is my topic of the year as well and quite some stuff got moving there already. For example, we aligned in the team on an application security strategy to get where we want to be, and already took steps to get closer. I had a few sessions together with our awesome InfoSec folks to build security in, test together, and gain more clarity on specific topics. Also, I joined my very first security audit and officially took over the role as security champion for my team. More is in the making.

Finally, I still continue having monthly security testing sessions with Peter Kofler. We kept doing these ever since my Testing Tour back in 2018, we just never stopped! We're not moving fast yet continuously. This way, we could already cover lots of ground in theory and practice together. Well, there's always more to learn and always something new going on, we won't run out of topics any time soon. It's been great to see how much we can build on the insights we gained over the years.

Probable Next Steps

Well, I don't know what life and this challenge brings, yet I have a rough plan on my next moves.

I'll see what I can do to get more active in the communities I'm already in, seeing where I can find help and inspiration, and also practice giving back as much as I can already. I'm considering joining more communities, so I'll continue seeking recommendations. I'm also looking out for events that might still suit my schedule this year, and probably bring my topics to the events I'm already going to.

It'll soon be time to decide on my first hands-on challenge around mobile application security that I can share about and get feedback on. This will also include finding safe ways to practice and share without causing harm.

Finally, I'm still gathering and consuming more resources on application security in general.

Reflections for Moving Forward

This year was full of distractions so far. Over and over, I allowed myself to be pulled away from my personal challenge. Then my brain got so tired that I just kept working on these distractions which I perceived way easier than doing the scary thing, and they kept me nicely busy anyways. Yet also more guilty with every step. Especially considering my usual timeline for personal challenges from January to October. Seeing so much time having passed already without much progress is frightening and paralyzing. Having too many options what to do next, is too. The last months, my brain kept jumping between too many threads, and not producing the clear structure I dearly need to hold on to and not get lost.

Also, why didn't I ask more of my existing network connections yet, as I do know several folks who work in security? For other topics I did that a lot, so why not here? After all, I'm not alone - and the whole topic is about reaching out!

Well. This challenge is indeed scary for me. 

Is it because security is such a vast area of expertise? Or maybe because it's difficult to impossible to share about real everyday work challenges? I liked to believe so, yet on the other hand I had similar situations already where there was always a way to still learn and share. I wonder if it's because I interrupted my streak of personal challenges and can't build on the past momentum of learning in public to the same extent. Maybe it's because it's very long time ago since I had to join a new community, especially online compared to mingling at on-site events - and it's difficult to have to prove myself all over again. Or it might just be a tough year for me, and that after a few years of drained energy - which might cause my fear overshadow my curiosity and hope. Heck, maybe I'm once again overthinking way too much. Probably it's all of it combined.

Maybe it'll get easier once I can focus my head on hands-on challenges. Right now, consuming resources and practicing would feel closer to my comfort zone than making my way into security communities. But that's exactly what I am aiming for.

I should indeed take my own advice and do a bit every day, just a few minutes, yet every day. Tiny steps go a long way and still result in lots of practice in the end. For that, I have to be okay with good enough for now, and not worry too much about my originally envisioned timeline that clearly didn't work out this time - which is fine.

So be it. Slow steps it is, and I'll become okay with it. As long as I do take the next step it still keeps me moving in a generally good direction. At AgileTD Open Air, Janet Gregory shared a quote by Paulo Coelho that really hit home for me: "An arrow can only be shot by pulling it backward. So when life is dragging you back with difficulties, it means that it’s going to launch you into something great. So just focus, and keep aiming."