Useful training and mindset for becoming a Cloud Security Architect

A couple of weeks ago I was asked by my colleague to give him some clues and tips on how to become a Cloud Security Architect, as that’s the venture he wants to follow and he knows I’ve been in architect-alike roles for a while.
Knowing how much fulfillment one can get from a good career and work-life, I’ve had decided to sit down and write down some tips right-away. I did share it with him, but then I’ve had looked at it myself and I’ve come to realize that instead of a few tips, I happened to write a lengthy article on the subject. So I’ve polished it a bit and wanted to share this with you.

Please note, that I’m never in this article claiming that this is the ideal path, the only path or anything of that nature.
I’m no guru, no career expert or some crazy good security architect.  I’m just a dude who happened to manage to get to the point I’m right now, and I want to share my perspective as a mean to help you see the journey of others and maybe get some clues on how to proceed with your career.

To me, the role of a security architect is as much about technical work as it is about business and leadership. While the specifics of the role definitely vary between companies, it’s a common requirement for architects to know how to talk to C-level executives, lead teams and independently manage the workload in such as way that the project gets delivered in compliance with the business requirements. Sometimes reading through the job descriptions you may get the impression like the productivity of a security architect equals their social-savviness and there is something to it. Rarely you can build great things without the involvement of great people and if you can’t influence them to follow your leadership, then you’re missing out on a huge potential of the group work.  But I published a whole book on how to level up your social skills game to boost your career in infosec, so I’ll skip that and will focus on other aspects of the role.

My path isn’t obvious but it’s very common

In my case, I can’t really speak of any certifications or training aimed at becoming a security architect – if you know some, please leave a comment with some about it – but I have completed a bunch of Cloud Security Architecture related courses and training, which I believe helped me tremendously in getting better.

I haven’t had any formal education that got me into the role of a security architect, but rather a lucky series of opportunities that presented themselves in front of me and I was able to get hold of them.
To cut it short, I’ve started gaining exposure to the commercial IT about 10 years ago. I’ve started as a programmer, then became a network administrator(netops), sysadmin, bug bounty hunter, pentester, offensive security engineer, security engineer working in a blue team focused on SOC/IR. During that time I’ve been focused on self-development to mature – as each human should – both in personal and professional life. I’ve made sure to keep myself educated on business, social dynamics, relationships and all types of things, to get more context and wider perspective. It took quite a while, but I feel that the appreciation to the challenges faced by people on different roles and different levels of seniority eventually made me a better security architect.

Like I’ve said earlier, education never stops because you always learn new things on the go and try to be prepared for new projects. To stay as current as I can in this fast-paced industry, I try to take advantage of the content shared by people generous enough to share their knowledge. I can’t really express the level of gratitude and admiration I have towards people who’ve had done something and then have decided to share their knowledge on the Internet. You can really, really learn a ton by following what others have tried, what they succeeded in as well as what they’ve failed at. Each lesson holds enormous value, regardless of it’s a study of the success of a failure – you’re focused on studying somebody’s attempt and then deciding on how you can put that knowledge to use in your particular real-life scenario.

Recommended technical training for Cloud Security Engineering and Architecture

When it comes to the cloud I’m really a fan of vendor-specific training and certification, because due to the complexity of each of those environments, the generic training just doesn’t cut it.
Vendor-specific training allowed me to much easier navigate through the piles of knowledge I’ve collected along the way while playing with various environments on different projects and helped me put a solid structure around the knowledge I’ve had from reading blog posts, articles, podcasts and whatnot.

All of the leading cloud service providers – Google, AWS and Azure – have fantastic training and certifications that prepare you for hard scenarios you’ll face in real life. I’d say that before the training I’m about to mention, I used to cope with the security in the cloud and each and every next training made me feel like I’m more thriving in those environments rather than fighting each day and stressing about every little thing, dreading the unknown.

After having a few years of average-quality experience in playing with various cloud environments, I took enormous value from signing up for the following training which I’ve completed over the years:

Google Cloud Platform(GCP): 

Google Cloud Professional Cloud Architect
Google Cloud Professional Associate Cloud Engineer
Google Cloud Professional Professional Cloud Developer
Google Cloud Professional Cloud Security Engineer

Amazon Web Services(AWS):

With AWS they have a few tiers depending on your experience so I’ve always tried to opt for the Professional level, as it’s much deeper and for a security professional who doesn’t like getting unpleasantly surprised it’s excellent as it provides more depth in many critical components.

AWS Certified Cloud Practitioner
AWS Certified Solutions Architect
AWS Certified DevOps Engineer
AWS Certified Security Specialty

Microsoft’s Azure:

I haven’t participated in any big projects related to Azure, so just to have some overview of the platform I took the following courses:

Microsoft Azure Security Technologies
Microsoft Azure Architect

And when it comes to really generic training or certifications, I’ve enrolled for a course preparing for ISC2’s Certified Cloud Security Professional training which was nice but I probably should’ve had done it years ago to really benefit from it.

Note that I haven’t gotten myself to go after the actual corresponding certification after completing the courses/training, because to me the paper isn’t worth spending $500 per each and stressing about my scoring. It’s just my personal decision and I’ve never been interested in spending money on things that don’t directly improve my working knowledge, but it doesn’t mean you shouldn’t do it. If you want to spend the money or you have the company covering your training + certification costs then, by all means, go for it, because for some employers it matters and some folks enjoy passing the exam.
To me, during my whole formal and informal education I was never excited about passing exams. I guess it’s just my nature, because I’m always looking at the next thing I’m going to do after finishing something and I’m more excited about getting myself into the next course and using my money to grow and through my professional growth be able to bring more value to the company I work for.
The cost vs benefit ratio never made sense to me, but I wanted to write this paragraph to let you know that it’s not necessary but if you want to – go for it. Still, this is just my opinion of a guy who’s pretty conservative when it comes to spending money.

At the end of the day, a security architect is a role where you don’t just build secure software or secure infrastructure. Your point of focus is on building a security company/securing your business, which is where big-picture perspective gets beneficial, so while I focused here on the cloud environments, I think you should really try to make yourself familiar with as many building blocks of your company as possible. Obviously, you need to assess what’s beneficial and what not and what type of sacrificed you’re willing to make, but I’ve never seen anyone’s career being hindered by knowing too much.
Even though I’ve started working in the role of a security architect over 4 years ago, I’ve all that time focused on becoming. Becoming better at being a security architect, because getting into that position is just a test of your basic abilities required to get an opportunity to start the journey of becoming a good Security Architect.

To sum it up, if someone is wondering what to do to become better I think the training/certs listed above are a fine way to go about it. I’m not saying it’s the best or the only way to do it, but if you have no idea where to go next – which was the case for me for a way too long time – then it’s better to pick either of those and do something. It’s always better to do some than do none.

All the best to Y’All,

[PL] Jak przygotować się do zdania certyfikatu OSCP

Całkiem często pojawia się w polskim community pytanie odnośnie tego jak poradzić sobie z certyfikacją Offensive Security Certified Professional, więc uznałem, że troszkę wypada dorzucić swoje trzy grosze biorąc pod uwagę to, że w ciągu ostatnich 3 lat rekrutowałem kilkadziesiąt osób do różnych działów cyberbezpieczeństwa i sporo z tych osób próbowało swoich sił właśnie z OSCP.

Obserwacje sceny globalnej jak i prywatne doświadczenia sprowadzają moją opinię na temat zdawalności OSCP to następujących sugestii:

Najlepiej do egzaminu przygotują Cię laby PWK, a powtórka egzaminu jest tania jak barszcz więc nie masz się czego obawiać.
Co do mocnych zasobów z tipami to polecam wpisy na blogach ludzi, którzy dokładnie opisuja swoją drogę przez mękę tzw ‘Try Harder’ 🙂
Googluj po słowach kluczowych takich jak “My OSCP Journey” “Journey to Try Harder”
Tutaj przykłady takich zasobów z mocnym zgrupowaniem personalnych historii:
Sam OffSec ma na swojej stronie linki do testimonials ludzi którzy konczyli certy. Nie pamiętam dokładnie linku, ale na pewno na githubie jest repo które linkuje setki writeup’ów ludzi którzy przechodzili przez certy oscp, więc polecam sprawdzić ten kierunek + na twitterze są hashtagi #oscp #tryharder z których mnóstwo personalnych historii wyciągniesz.

Historie pisane życiem są najlepsze i community ‘Try harder’ bardzo dużo energii zazwyczaj wkłada w swoje blogposty, więc powinno Ci się spodobac.

O failu z buffer overflow pierwszy raz słyszę – zarówno w PWK jak i na egzaminie OSCP zadania związane z low-lvl exploitation są mega łatwe(kilkanaście minut do rozwiązania) i nie znam nikogo komu by się nie powiodło 🙂Często to zadanko się robi na początku na dobry start, bo o ile ma trochę punktów to jest takim słodyczem na zachętę.

Natomiast bardzo często egzaminy ludziom padają ze względu na braki w wiedzy/doświadczeniu związanym z privilege escalation.

W każdym razie – nie macie się czym stresować, laby PWK wszystko Wam wytłumaczą a na egzaminie nie ma niczego czego nie byłoby w labach.

Co do maszyn vulnhub/hackthebox/attackdefense jak najbardziej na +++++

A co z innymi certami takimi jak Security+? Na to pytanie odpowiem w dłuższy materiale już niedługo, natomiast na tę chwilę wrzucę:

Jeśli dobrze pamiętam to cert Security+ to ~1.2k PLN, więc jeśli zależy Ci na dobrym ROI to lepiej zainwestować te pieniądze w sensowniejsze zasoby.
A jeśli chcesz się nauczyć materiału, który obejmuje Security+ to generalnie jak najbardziej polecam bo dużo z tego można wyciągnąć. W tym kierunku polecam darmową serię mega dobrych nagrań Professora Messera:

Ten kawałek wiedzy jest darmowy jeśli klikniesz w zasób który podlinkowałem. Kosztowny jest cert, który jak ze wszystkim w życiu – przyda się, ale i bez niego da się karierę poprowadzić.
A tak mówiąc już brutalnie szczerze – szukaj raczej miejsca pracy w którym zweryfikują Twoją wiedzę i umiejętności(gdy np. wykażesz się dobrą znajomością materiału z kursu p.Messera), bo tak w życiu się często składa że koniec końców firmy które postrzegają pracownika przez pryzmat papierów czy innych bzdur jak kolor włosów, to często firmy w których i tak szkoda marnować życia na pracę:)

Jak przetestować bezpieczeństwo własnej aplikacji i serwera

Często w sieci trafiamy na pytanie “w jaki sposób przetestować bezpieczeństwo mojej aplikacji/mojego serwera”,  na co chętnie odpowiadamy zarywając kolejną noc i pisząc kolejny esej.

Z esejami w branży security jest tak, że o ile fantastycznie pomagają nam podbudować ego, to niewiele rzeczywiście wartości wnoszą do życia osoby, której wydawało nam się, że chcemy pomóc.  Cenię sobie każdego kto ma dobre intencje i poświęca swój czas by pomóc innym, ale po wielu latach w infosec, trzeba przeprowadzić reality check i spojrzeć prawdzie w oczy.

I ta prawda trochę w oczy zapiecze, bo okazuje się, że często nasze działania mijają się z celem. Zamiast dostarczyć komuś narzędzi za pomocą których osiągnie swój cel, to zarzucamy ludzi mnóstwem informacji, które same w sobie są wartościowe, lecz większość programistów/sysadminów po prostu nie ma czasu na analizowanie tak głębokich wypowiedzi.

W większości sytuacji, dobra rada to taka, która pozwoli komuś skutecznie rozwiązać problem, a wszystko dodatkowe to tylko szum.

Jeśli jesteś osobą zainteresowaną rozwojem w branży bezpieczeństwa IT, to śmiało rzuć okiem na moje długie artykuły/podcasty/szkolenia online w których obszernie wyjaśniam wiele tematów.  Natomiast jeśli nie chcesz zmieniać całej swojej kariery w kierunku infosec i chcesz po prostu sprawdzić podstawowe zabezpieczenia w swojej aplikacji, to na pytanie:

Jakie narzędzia automatyczne pomogą mi przetestować moją prostą aplikację na localhost+XAMPP?


 Jeśli to localhost i chcesz się pobawić, to pobierz sobie Armitage i puść Hail Mary z agresywnymi exploitami z metasploita żeby Ci napsuł tyle ile się da.
Do tego z narzędzi, które są point & shoot to 99% tego czego potrzebujesz załatwi Ci:
OpenVas (opensource alternatywa Nessusa, tj. bezpieczeństwo sieci/hosta + znane podatności oprogramowania zainstalowanego na hostach – wliczając webappki)
OWASP ZAP – do dynamicznego testowania bezpieczeństwa aplikacji webowej

Zarówno w Armitage, OpenVas i ZAPie daj im dane logowania do hosta z najwyższymi uprawnieniami, tak żeby mogły przeorać wszystko co możliwe.

Z w/w narzędziami przeprowadzisz atak na >98% świata, XAMPPA wliczając 🙂 Pobierz narzędzia, pobaw się, daj znać gdy pojawią się pytania.

Enjoy 🙂

A gdy pojawią się jakieś pytania, to najprawdopodobniej ktoś już kiedyś wpadł na podobne pytanie i odpowiedzi na nie znajdziesz już dostępne w sieci, więc spróbuj najpierw pogooglować i pobawić się samemu. O ile generalnie rzeczywiście zaoszczędzisz trochę czasu w danej chwili jeśli spytasz kogoś o radę na tematy które były już poruszane setki tysięcy razy, o tyle długoterminowo lepiej będzie dla Ciebie jeśli przyłożysz się do własnego researchu i praktycznego dotknięcia tych wszystkich narzędzi/systemów.

Krąży po świecie taki ładny cytat, który przez swoją ponadczasową mądrość jest przypisywany wielu wielkim – od Konfucjusza, przez Lincolna po Franklina. Więc przytoczę go też i w tym blogpoście, bo niewiele w życiu prawd jest tak aktualnych jak właśnie ta:


“Tell me and I forget,

teach me and I may remember,

involve me and I learn.”

Do roboty! 🙂

13 basic steps to start a practical implementation of DevSecOps at your organisation

Hello Friends,

I want to share with you a blogpost I created as an attempt to bring some more clarity to the concepts that are [finally] getting more attention of the public.
I’m a solid believer that the potential of the tribe can be tapped into it’s full extent only if all the members of the community are able to communicate freely with each other and exchange the ideas. Same way we can’t solve a problem if we don’t know if there is a problem or what is the problem, I believe for us to innovate and bring our ideas to fruition we need to our language and simplify the overcomplicated terminology. But that’s just me being me with my lengthy intros to what’s about to come next, so let’s cut it short this time and get to the specifics.

Secure SDLC requires multiple steps to be completed in order to secure whole software delivery cycle, although each step alone significantly contributes to overall security posture of an organisation. Implementation of Secure SDLC in AgileDevelopment requires transformation of traditional collaboration workflows, where security teams worked as an independent consultancy offering their support on demand basis, whenever needed by software engineers. With Agile development where speed is the most important variable, there is a need for shifting security to the left of SDLC, minimizing exposure in later SDLC phases and decreasing the costs of remediation of security issues when they’re discovered. Besides the decreased total cost of software development, DevSecOps brings a concept of servant leadership to the security ecosystem, improving the overall culture of the organisation and reducing the friction between security operations and all other employees.

I like to explain the practical difference between Secure SDLC and DevSecOps in the following way:


SSDLC is meant to answer the technicalities of the vital questions in any transformation process, i.e. “what”, “when”, “where”, “how”, and “why” and in this particular context it’s pretty much meant to address what’s been known since 2002 as Microsoft’s SDL. You can read it as processes, procedures, tools etc. which you plug into your SDLC workflow to ensure that each phase of SDLC has a corresponding security instrument initiating some sort of activity meant to reduce the security exposure created by/in the final product.
DevSecOps is then a cultural movement meant to ensure everyone across the whole organisation understand the answer to “why” well enough to actually want to care about all those security things.
To follow SSDLC is to prepare an environment which just makes your products and organisation safer. To advocate DevSecOps is to encourage people to put in use all the great things you’ve prepared for them with SSDLC setup and to not despise the additional burden – rather to enjoy the vision of being able of supporting the common effort to ship safer products which support the bottom line of the company which in turn takes care of its employees.

To me, it’s all about using all the instruments available to create a win-win environment, and that requires a willingness to work on bringing everyone on the same page with the cultural transformation of your organisation.
If you as a security professional aren’t willing to believe that you can manage collaborating with other people at your organisation(be it engineering, sales, helpdesk, the board and all in between) you won’t be able to bring a meaningful change. We know how this story goes, because for the past few decades we’ve tried to convince other people to do something just for the sake of doing it and we see where it got us, so it’s about time to try another approach. And that DevSecOps is what I call an empathetic and result-oriented approach of tackling the security challenges of the modern software-related companies.

Although this explanation seemingly ignores a significant amount of details and may be looked upon by experts as over-simplistic, it just gets the job done. If you’d like to learn more about the effective means to use a language as a tool for getting your job done, you may want to take a read of the following article:
And here is a list of 13 specifics that I like to use as an initial outline of the attempt to analyze the scope of the transformation:

  1. Create a roadmap for an education of all technical stakeholders such as software engineers, QA testers, product owners and engineering managers on secure software engineering. Education process should include trainings/workshops meant to increase the technical skills related to secure programming as well as making employees aware of corporate securitypolicies, procedures, processes and best practices. The later provides employees an opportunity to obtain a wider perspective enabling them to come up with their own ideas on how to build a contextual defense mechanisms linked to the feature they’re developing at the moment.
    Security training should be conducted in a form of interactive workshops, to create a personal bonds between security staff and other employees and to increase the odds of personnel remembering the entertaining learning experience. Going forward, employees should have access to comprehensive knowledge-base e.g. in a form of automated learning platform that allows access on ad-hoc basis when they need to learn about safety of currently developed software module.
  2. Educating all business units on how security should be instilled into SDLC and day to day work of their teams. Approach top to bottom helps ensure that the management actually provide employees needed resources to do their work securely.
  3. Creating a culture of collaboration between security and all other departments in the spirit of DevSecOps, which emphasised empathetic and servant leadership. Security team should be deemed an indispensable member of each department, sharing their knowledge as well as acting as Subject Matter Expert in their domain of expertise – as opposed to an external silo which receives a cold requests to perform security testing of an already developed product.
  4. Deploying systems and code auditing tools to ensure higher coverage of security assurance. This includes involvement of automated scanning technologies across the whole technology stack used by an organisation. Implementation of those tools not only helps to identify security issues, but also by delegating remediation to a person that introduced a security flaw, enables practical education process where employees understand what they should do better in the future.
  5. Defining explicit minimum security requirements for each new application, where software engineers understand how things should be ran at the organisation in compliance with security-related departments. In Agile world, each back-and-forth with security team is a waste of time, which is why all documentation must be prepared upfront and delivered to relevant stakeholders.
  6. Creating quality bars that define on which risk levels it’s feasible to fail the build and not allow software to reach production, based on the assessment performed by automated systems for code scanning, dynamic application scanning, config auditing as well as manual testing.
  7. Incorporating one-time manual and automated threat modeling and design reviews. Reviewing software design at earliest and final phase of SDLC enables you to provide contextual guidelines for development teams, as well as to prepare security department for risks associated with development of very specific software so that all entities are prepared for reverification of mission critical components. Training product owners and systems architects how to create threat modelsallows to perform risk analysis at lower cost without direct involvement of a security team.
  8. Defining automated tools, benchmarks, security checks and baseline which explicitly enforces usage of specific security safeguards. Think of always enforced compilation flags on a build server, where security is bolt-in by default.
  9. Deprecating unsafe software and dead code. Automated analysing software for dead code as well as insecure and outdated dependencies significantly lowers the risk profile of an organisation and developer software. If automated systems are in place to achieve this, then software engineer can immediately react to an alert about insecure dependencyand upgrade the library in subject to secure minor version with security patches without significant impact on systems stability. Not upgrading libraries often leads to situation when there is too big difference between version used and expected, which may introduce too many changes to the system, which in turn increases the costs of software development by requiring additional testing performed by manual QA engineers .
  10. Performing Static Application Security Testing. SAST tools are should be plugged into Continuous Integration & Delivery pipelines to run automatically after each change to the system – such as each new commit to Version ControlSystem – and periodically, independent of release schedule.
    Software Engineers should be also allowed to swiftly run those tools independently on their machines at as low cost as possible.
  11. Performing Dynamic Application Security Testing. DAST tools should be plugged into Continuous Integration & Delivery pipelines to run automatically after each change to the system and periodically, despite release schedule. Software Engineers should be also allowed to swiftly run those tools independently on their machines at as low cost as possible.
  12. Performing Fuzz Testing, which is sending to an application unexpected types of random data that helps undiscover security issues that may be affecting whole CIA-triad(Confidentiality, Integrity, Availability). Fuzz testing is important to mention here, because while most of the automated systems are meant to ensure company’s compliance with certain standards and security baselines, fuzz testing is meant to expose unexpected security flaws that may have went under the radar of automated tools and software engineers.
  13. Performing manual review of tools and documentation output pre-release, to ensure high quality review with involvement of a human element.

In any case, I hope this article comes useful to you – whether you’re trying to gain a bit of an infield perspective into the world of Secure SDLC & DevSecOps, or if you’re a security professional looking for some basic steps to kick-off the process of trying it out at your organisation.

Have a great weekend Y’all and I’m looking forward to your feedback!


PS. More content on this subjects coming out soon 🙂

Własny LAB do nauki pentestów – jak zacząć

Niedawno na Facebookowej grupie “Testowanie Oprogramowania” pojawiło się ciekawe pytanie:

Próbuję się przekwalifikować z testera manualnego na pen testera. Zmieniłam teraz pracę i jako pierwsze zadanie jako nowy penetration tester zostało mi polecone zbudowanie laba. Narazie nie wiem jak zabardzo to ugryźć.

Ogólnie dopiero formujemy security team więc wszystko jest jeszcze bardzo płynne. Docelowo lab ma służyc do werifikowania security vulnerabilities w naszym produkcie. Plus narazie mamy firmę która raz w roku robi nam pen testy ale chcemy to zacząć robić sami, więc to ma też być pewnego rodzaju playground

Na które jako tako udało mi się odpowiedzieć, więc wrzucam też na bloga dla potomnych:


1) Jeśli pytasz o LAB w kontekście środowiska gdzie możesz się uczyć testować bezpieczeństwo, to ten artykuł opisuje praktycznie wszystko co jest Ci potrzebne żeby wystartować i mieć czym się zająć najbliższy rok (jest stack webowy do testowania webówki, i jest też metasploitable do wdrożenia w pentesty infrastruktury).…/
Masz tam też wypisane informacje odnośnie narzędzi, które powinnaś wykorzystywać jako swoje środowisko pracy do przeprowadzania testów, tj. wszystko począwszy od local proxy, przez automatyczne skany podatności, po nasłuchiwanie ruchu sieciowego.
Kilka innych zasobów, które pomogą Ci zbudować LAB w obrębie kontekstu, którym jest piaskownica w której możesz się bawić i rozwijać swoje umiejętności.…/…/basic-penetration-testing-lab-1…
Przyda Ci się też książka Georgii Weidman, która mimo że jest już trochę przedawniona, to w bardzo ustrukturyzowany sposób przeprowadzi Cię przez to jak profesjonaliści infosec tworzą środowiska do samorozwoju:

2) Jeśli pytasz o konkretne narzędzia i to jak zrobić LAB do samorozwoju na większą skalę, to po prostu przyłóż się do OSCP. Napisałaś, że robisz OSCP, a Laby PWK to jedno z najlepszych środowisk na świecie z których wyciągniesz zarówno konkretne umiejętności techniczne jak i zobaczysz w jaki sposób zbudowane są LABy składające się z kilkudziesięciu hostów.
Po OSCP jeśli interesują Cię desktop appy, to nie popełnisz błędu idąc w kierunkcu OSCE.
Niedawno Offensive Security wypuściło jako kurs online szkolenie i certyfikację dla pentestów webowych, tj. Advanced Web Attacks and Exploitation (AWAE) + OSWE

3) Czytając jednak Twoje komentarze, odnoszę wrażenie że firma chce żebyś zbudowała środowisko typu piaskownica służące do testowania bezpieczeństwa produktów które wytwarzacie. Tutaj rocket science nie będzie, bo potrzebne jest zwyczajne środowisko z jakiego korzysta do testów Dev/QA w Twojej firmie. Natomiast jeśli chodzi o drugą część tego środowiska, tj. podpięcie narzędzi do ciągłego zapewniania wysokiego standardu bezpieczeństwa produkowanego oprogramowania to odsyłam Cię do zasobów opisujących praktyczną implementację Secure SDLC:…/securityengin…/sdl/practices

Przykładowe narzędzia masz opisane tutaj:

A do aplikacji desktopowych powinnaś zapoznać się z fuzzerami jak np. American fuzzy lop oraz narzędziami do statycznej analizy kodu, tzw SAST, np. OpenStack Bandit.
Listę tego typu narzędzi znajdziesz tutaj:

Tak więc powodzenia i trzymam kciuki za Twój dalszy rozwój kariery – jest co robić! 🙂

Jako dumny gość drugiego odcinka podcastu QAudycja!

Tym razem miałem zaszczyt pojawić się jakos gość w drugim odcinku nowego podcastu Konrada z QAudycja​.

Opowiadałem o karierze w bezpieczeństwie, o cyberbezpieczeństwie Polski oraz mojej nowej przygodzie zawodowej.
Klasycznie pojawiła się też garść informacji o codziennym radzeniu sobie z życiem, w szczególności o intensywności, ludziach dobrych i negatywnych oraz o wpływie środowiska na to jak kształtuje się nasza ścieżka prywatna i zawodowa.

Serdecznie polecam, bo poziom pytań Konrada był fantastyczny a On dopiero się rozkręca!
Trzymam kciuki za sukces jego bloga oraz podcastu 💪.

TestDive 2018 – DevSecOps implementation i.e. a culture of care

This year, I was invited to speak at TestDive 2018, an event sponsored mainly by Nokia and organized by fabulous people working at Nokia Kraków. It’s a great honor when someone asks you to talk at the conference of such a scale, and I was the lucky one this time.

Based on the amount of great feedback that I’ve received after the talk, it sounds like I did quite okay 🙂 And that’s awesome, because the subjects I talk about are rarely sexy. It’s practitionership, it’s effectiveness, and more often than not it’s far from flashy and overhyped solutions.  Cyberresilience isn’t a state you achieve by plugging in that one overpriced box into your network, or by hiring that one security guru. It’s about constant education, collaboration, understanding and daily grind meant to move a needle just a little bit.

Rome wasn’t built in a day. But it also didn’t collapse over night. Everything takes time, and if you’re not actively focusing on building the right culture, you’re ultimately ruining it.  That’s what the game is all about, just the grind and doing what needs to be done.

Anyways, I want to definitely send some love to Robert Becker who invited me to be a speaker, and who guided me through the whole process. It’s been a busy few months for me, so having someone like Robert helping me out and pinging me whenever I’ve forgotten to provide about some info was invaluable. You could feel the same sense of ownership during the conference, where everything was prepared top to bottom. We had fabulous announcer; great assistants from Nokia(thanks Maciej!), great atmosphere and venue was spot-on.


I do believe this was the most friendly conference I’ve attended this year. I don’t know what it was, and how that happened, but literally the moment I went through the doors I’ve felt like that’s it. I’m really looking forward to TestDive 2019’s edition,  and for one more time I want to say that I’m extremely grateful for being able to go on stage and share my experience with people who care enough to invest their time into listening to me, while they could be consuming the knowledge of other great speakers.

Love you all, your feedback is my oxygen. Now go and make some ruckus! 🙂


Here’s the link to the presentation:


And here are the links to three parts of my book. The rest will follow the editorial redaction process and will be uploaded to my blog when it’s ready.





and my YouTube channel as few of you have asked for it:

Social Skills For Information Security Professionals: On Agile, Secure SDLC and Unhealthy Habits

Agile implementation of security into a corporate culture

Start small

I recommend you to take baby steps with all of the security initiatives you want to start at your company. By balancing the workload and adaptability you can demonstrate coworkers and executives that security doesn’t need to be tangled and complicated. If you show people that it takes just 5 clicks to enable disk encryption to improve safety of their PCs, it’ll be easier to have discussions with them in the future. After you’ve accumulated a few such small-wins, their mindset will change and they believe there actually are hassle-free solutions to security, they’ll be more eager to implement more of it.
Focus on the small wins and do the things that have the biggest ROI(Return Of Investment) and lowest cost of implementation and then steadily increase the complexity of security requirements.
1% is always better than 0. Small win executed today is better than an ideal win executed never.


The common mistake I’ve seen is that we  try to start out too big. We want to enforce all the security rules as soon as possible and sometimes even worse – all at once.
This approach may sound reasonable from a security pro’s perspective, because time is all we’ve got and each minute with security exposure is a minute an attacker can get a foot in the door.
However, it’s a complete failure from a practical business POV and I haven’t ever seen it being successful in the long-term perspective when someone tried to execute too many and too complex things at once.

Human beings are wired in a way that makes them dislike leaving their comfort zones, because the primitive part of our brain was programmed to keep us alive by avoiding risks.  In order to fight that, you must give people a tangible incentive for them to take a leap, because they must justify in their own heads why this particular risk is worth taking. Bigger your demand is, bigger the incentive should be, because the potential gain must be big enough for people to fight back the alerts their primitive brain is giving them. Yes, although nowadays we’re rarely required to make decisions that can kill us, that thing still resists when challenged with something new, because it doesn’t understand that discomfort . All it knows is that it must protect us at all cost, and it’s up to us – or actually other parts of our brain – to take a brave decision regardless.
It’s a good idea to start smaller with things that don’t push the comfort zone that much to earn the trust of your people. Most people are open-minded, but not that open-mindedly stupid to be leave their safe spot on the day 1, when they don’t know how good of a leader you are. And that’s for a good reasons, it’s not them to be blamed. People just want to be safe and we should respect that.

An example may be a common situation when you want to start implementing Principle of Least Privilege within your organisation. You shouldn’t just cut off coworkers access to all of their productivity tools, they were used to utilize on daily basis for the past few years. Do it in many small stages, one tool after another in reasonable time spans, otherwise you may outrage people when they lose access to things they were used to use freely. Not only it may cause them a discomfort but it can negatively affect the business when people’s morale are low, and their productivity is lower because they don’t have the tools they need to get the work done.

Building security is tough, not because it’s that technically complicated, but because it takes a lot of time, perseverance, patience and leadership skills. If you’re joining an organization that’s been on the market for a couple of years and never had a security person/culture before, you must prepare yourself for slow rollout of all those great ideas that you have.
It’s because people, who were never trained to be security-savvy, will have hard time adopting new requirements , even if you have reasonable justification for it. People like what they know, what they tested and know to be working and what feels like right for them. Because of our recklessness and mistakes we’ve made in the past 4 decades, we have earned not friendly reputation around infosec. It makes a lot of engineers think that security will make their work suck, so they do everything in their powers to stay away from it.

The best way to build credibility and have immediate results without irritating people is to start with subtle changes like showing the value of strong passwords, password managers, 2 Factor Authentication, Antivirus and frequent software updates . It may sound like nothing, but all adopted across the whole fleet will result in good security baseline that already puts your company in a few TOP % of safest companies. Even though those are the basic things and infosec folks like to go for fancy and overhyped security measures, I can count on fingers of one hand companies that actually have implemented above mentioned basics and done patch management right. That’s just an example tho.

That’s it, starting small is important. You won’t get much love for 30 days password expiry, enforcing security product with terrible UX or for cutting off access to critical services, just because you haven’t done good enough research to learn what is it, that people need to get their work done.

Start early

I can think of at least two main reasons why it’s reasonable to start with security at the project’s earliest. One, is that if you create a security culture in your organisation from its early days, you won’t give people a chance to learn bad habits of ignoring security. Second, is that it’s more expensive to change architecture design and refactor a finished product. Changing habits which essentially is rewiring brains of your employees is a very expensive ride, so it’s better to avoid such challenges altogether and instill security from the employee number 1. Everything that’s happening in the organisation is CEO’s responsibility and if she/he doesn’t set a healthy tone from the day 1, it’ll be hard to teach people to follow the practices, if they know even CEO doesn’t walk the talk.

I recommend all-sized businesses to look for the help of security consultant as soon as it becomes affordable. I wish more companies realized that asking for a few hours of consultancy won’t ruin their budget, but can have tremendous ROI. It can create a baseline upon which they can build their stuff securely from the day one and avoid costly refactorings or breaches in the future.  Chances are that if you give it a thought, you’ll remind yourself that you personally know some security passionate who’ll be more than happy to support some startup free of charge in exchange for business experience. She/he can help you ensure that products are well secured, so people in need should reach out to their social circles and ask for help as soon as possible. It costs them nothing, and even if they find a kid who’s been studying appsec for barely 6 months and can work for you only part-time, it’s still better than doing nothing at all.

I’m writing this to demonstrate two important things we don’t pay enough attention to. If you’re a security specialist and someone is asking you for advice, you should emphasize the importance of starting early. Because if you eventually end up joining that company in the future, you don’t want to start from scratch and waste your energy on solving problems that could’ve been prevented from happening in the first place.

The other one is that when you join the company, expose yourself as soon as possible. Don’t close yourself in your office focusing solely on technical aspects such as deploying monitoring and pentesting the infrastructure. Go out there, and show people that you exist. Allow them to notice you, and give them relevant resources as fast as you can. Provide them with books, articles, tools, guidelines, checklists, procedures so they can already start applying it in their day to day work. Thanks to that the improvement will be happening in the background, when you get back into your zone focusing on other things.

Outline SDLC/NDLC improvements

Security should be perceived like any other cost of running a business

Security shouldn’t be seen as an addition to the product development. It’s as regular part of a business operations as anything else, especially when we’re talking about companies that develop their own software.
At software companies, ensuring security should be considered as a part of Quality Assurance, not only because security triad mentions Confidentiality, Integrity and Availability out of which 2 are heavily linked to the product’s quality. So there is that, but also nowadays customers demand products to be safe for their personal usage and professional usage, because they don’t want to buy a service which may have negative impact on their business operations. We’re living in times where we’re all connected to each other like never before and not a single company can exists on this planet without affecting others in one way or another.

Although it may sound obvious to you, it’s not you who I’m concerned about, because we – security professionals – can’t do anything on our own and the perception of all parties involved matters. You must instill security into organisations DNA in such a way that people truly understand what it is and how it matters, because it doesn’t really matter if you have triple-firewalled PC with a personal guard watching over your computer when you go to the toilet, if there are employees who think it’s fine to download pirated games on their corporate laptops.

Also, middle-management is much more eager to spend resources on security, when they perceive it as a regular, necessary cost of software development. There will never be enough money and time to invest in “additional” activities, so you must rewire their dictionary. Security is often called a no-ROI time-waster which adds complexity and slows down development process, so not only security itself costs a lot, but it also makes other things more expensive.
Unless you explain how and why security is important you may have hard time pushing security related changes into existing SDLC processes, and that’s fair because everyone has their own work they’re ought to protect. That’s something you got to really understand, because most often at the workplace importance and urgency, don’t come from  inner virtues and passions, but from the actual business impact. So that’s something you must comprehend to shift your mindset and help everyone across the board understand what impact may insecure product have on your business, because except of us, no one is there to do security for the sake of doing security.


Hold them accountable to high standards, but keep your expectations low

Settle down on how much resources can be dedicated on security improvements, bugfixes and alike.
Discuss how many hours in each development sprint can be dedicated for security and how much free bandwidth does engineering have for potential unexpected security patching. Write it all down in internal documentation system or some other place that allows you to have an official proof that you had those discussions, so that no one can claim that you’re expecting them to do something they hadn’t agreed upon and twist out of the commitment. Each big goal is achieved by making many small steps, and altho it may look like some things should be done all at once, it’s most often not the case in real life. If you properly dissect your projects into smaller tasks, you’ll realize the value of small incremental changes and that big projects not only suck for time management, but they also tend to create a lot of friction with coworkers.
Focus on small but constant improvements, so you have the big goal in back of your head, however you don’t expect people to deliver it all at once. Not only it’ll make execution your projects on time more feasible, but it’ll also reduce the stress and boost team’s morales when they see 100% execution of a small task, rather than 0.1% progress on a huge project.

Let me make one remark here tho, because you really need to be wise when creating your expectations and demands. It’s not reasonable to expect business to stop all money-making activities and focus entirely on security for a few days or weeks to fix identified vulnerabilities. Use risk management to help business operate and help ensure it’s longevity instead of expecting impossible.

In my experience, it really makes a lot of sense sense to establish a fixed amount of resources that will be spent on ensuring security in each product’s release/sprint.
Sacrificing 3% engineering resources each day, is less painful than telling customer that you won’t deliver a mission critical feature, because you had to stop all your software engineering activities, caused by your security department having this unreasonable request of focusing solely on security for a next couple of weeks. Customers care about security, but not that much, to let you lag on service delivery.

Build secure SDLC

Security is more cost-effective if you start working on it at the earliest phase of SDLC.

Old tried and true, isn’t true anymore. The common practice of building a product and throwing it at a security team doesn’t scale anymore. Given how much code we produce on daily basis, it’s increasingly more expensive to not instill security in early phases of SDLC. At current pace we can’t afford waiting will last phase of SDLC, because a need for potential refactor of two weeks of code would come with dramatic costs.

Securing the whole workflow drives very tangible long-term improvements, because to me it’s less about catching issues earlier than it is about education that ultimately is something we’re looking for. Developers who’re constantly exposed to security work, will memorize more and more of it, keeping safety in back of their heads and  allowing them to fix the issues even faster.
We don’t want to see same mistakes over and over again, and unfortunately that’s something I still see at most companies all over the globe. Although the software engineering world moved forward a lot, security practices are still holding it all back and we haven’t globally addressed the basic issues that are so trivial to be remediated. It’s all about mindset and it’s all about moving the responsibility to the left and then making sure everyone is capable of taking ownerships of it.


While I get it that approach of black box pentesting was somewhat practical in the past, – been there and done that – nowadays most innovative software is too complex for security teams to secure the product in just few days before it hits production. There must be a whole lot of things done around it, which we’ll discuss in DevSecOps chapter later.

Surely there are small software houses with senior, security-savvy engineers where it’s practical to build a tiny product and then deliver it to security testers, because they cared about security while writing their code. But during my whole career having had worked with thousands of engineers from dozens of companies, I can name only a handful of such senior level of security-savviness so hoping that you have people who are somewhat competent in security isn’t the smartest thing to do.
Actually, hope rarely is a good strategy for anything in life. It’s good to have, but it’ll take you only this far.

However, if what you’re doing works for you, your company and your customers, then keep doing it. I want to emphasize it once again, that I’m sharing yet another perspective that if you feel a need to, you may want to try out. So while I’m advocating an approach of injecting security into whole software development life cycle, I realize that it is not a silver bullet and it may be too expensive for you at the moment. Yet still, I believe that 1% is much better than 0, so trying something is better than sitting stale and missing the right point when you were supposed to take action.
My recommendation always is to get involved in product design phase and keep an eye on the product throughout the whole development process. 

It’s all about cloud and dirt. About having the high level vision and long-term roadmap as well as doing what needs to be done to help you organisation achieve the goals.

Social Skills For Information Security Professionals: The Preface To My Book

On my motives for this book

How and why – I believe – can my story make your life easier

It’s been roughly 11 years since I’ve started commercially working in IT, out of which 7 were profoundly dedicated to InfoSec, a field in which I truly believe there is a lot yet to be done and that each individual can make a difference by their contributions. Similarly to the careers of so many of us, I’ve made a plenty of mistakes that had put my career at risk, significantly slowed down my growth, significantly lowered the income, as well as had negatively impacted my health and personal life. Although making mistakes should be an expected part of any worthwhile career, I had certainly not expected that along the way I’ll taste so many different flavors of life.
I’ve had my ups and downs, but I always tried to ensure that whoever was involved, came out with something beneficial to them. Despite having good intentions in my heart, not always was I successful in demonstrating that well. To me, everything I’ve been doing was always about bringing value to others and being the most productive person in the room, long before I have realized that I’ve had been doing it all wrong and my hunger for success was my biggest obstacle. But as the saying goes, “obstacle is the way”, which is why I’m grateful for all of it, and I really want to share my experiences with others, so they can save themselves some trouble and get smarter faster than I had. I wish I’ve had a resource that would guide me through at least the basics of human interactions and effectiveness in the business world. So here it comes. A book that I wish someone else gave me 11 years ago.

I want to be really upfront and transparent with you. Although the companies I’ve worked for were very satisfied with the outcome of my work, to me it came at the cost of my professional and personal relationships. Without any doubt, I can say that because of my stubbornness and improperly directed hunger, I’ve wasted a ton of my potential as well as burnt some potential in others. And that feeling sucks. Realizing that while chasing greatness I’ve had a negative impact on a quality of life of a few people around me, as well as looking at my own life and noticing how much health and energy I wasted – it just sucks. But it sucks in a different way than most things in life suck. It’s not about discomfort this time, but about an actual pain, because while I’ve got compensated quite fine for my around the clock grind, I’ve forgotten about the most important currency we have access to in our lives – time and health. If you’ve got good health and you’ve got time, you have all the resources necessary to makes something great happen. Assuming obviously, that you’re resourceful and can actually understand the value of these powerful two. That’s what I want to be the leading point of this book, i.e. how to achieve your goals quickly, yet without compromising quality of yours and others’ life. I respect your time, which is why I wanted to keep this book as concise as possible, cutting out the fluff each time I’ve noticed any. If this book takes you 2 hours to read, and it saves you as little as 1 day of your life – I’m all set. My mission is accomplished and I’ll feel good about it, because there is no bigger mission than saving lives. This is one of the reasons I’m publishing this book for free. I’m making fair amount of money on selling my time to the corporations, and I want these lessons to reach as many people as possible and help them preserve their time and health. I can make money by other means, but the opportunity to help people improve their health and relationships is so rare, and so huge, that I couldn’t let myself to agree for commercial publishing. I’ve been sharing my knowledge for the past 5 years all over the Internet, at conferences and meetups; and those few voices generous enough to share with me that I’ve helped them improve their lives, are the biggest reward one can get for their work. That’s what I hope this books will do for you – help you achieve your goals at lower costs of all involved stakeholders at all facets of life. I don’t want to monetize on this book. I want you to learn from it, and then for you to monetize newly acquired knowledge by improving as a professional and getting compensated well for your effort.
You don’t owe me anything and I don’t expect anything from you. You’ve already given me enough than I’m audacious to ask – your time and attention. Thank you for that, and if you still want to do something for me, then please share your experience and knowledge with others. Help you peers, show them your perspective and help them grow by exposing them to various point of views. Pass your knowledge to others, so they have it easier than you had. To help them avoid the mistakes you’ve made and so that they can save their time and use it to build something bigger or experience other thing life has to offer. Standing on the shoulders of giants. That’s what it all is.
I guess at this point you can already smell how much I dislike wasting time and reinventing the wheel 🙂

How and why – I believe – my story can make you avoid personal and professional suffering

Infosec is a stressful job and if not managed properly leads to unhealthy situations which surely can end up with a long-lasting burnout. Burnout is one of the most painful experiences in the life of a professional, especially a good one who is self-aware enough to realize how much of a potential they had and how it just got destroyed. There are many critics saying that the job-related stress in industries such as IT isn’t worth discussing, but I call that a dangerous misconception. You couldn’t get more wrong in thinking that we’re not under high pressure. InfoSec is one of those industries where many things are totally out of our control, and you can’t really sleep well – ever. Many of us got so engaged into the work we do that we started compromising other parts of our lives, introducing unhealthy imbalance. Precisely such imbalance led . So I can relate to all of us, who had experienced tough times. That’s one of the reasons I believe in this book so much. It’s not that it contains any secret knowledge, or that I’m such an egocentric writer. Heck, I’m not even a native speaker english speaker, so I realize my shortcomings, yet I am still ready to take the heat, because I believe in its value. I believe that this book can help – at least to some extent – my InfoSec friends who have struggled, struggle or will struggle with the challenges I’ve been struggling for many years. I hope this book answers some of the questions we ask ourselves and will turn out helpful especially to those of us, who have nobody to turn to for a practical and non-judgmental advice. Writing the book has certainly help me in understanding some concepts better and instilling them deeper into my mind, so I have the answers handy whenever I need them. And I need them pretty much on daily basis, so having this handbook on my computer allows me to stay in sync with reality and remain calm and humble.  

The tough experiences had made me who I am today, and with many bad outcomes, I’m getting more and more comfortable with helping others avoid my mistakes. Losing relationships, not taking care of my health which resulted in life-long illnesses and daily pain which decreases the quality of my life, had all contributed to the process of reinventing myself. Moments of the truest joyfulness were these where I’ve learnt that something can be done better. That I can do better and I can be better to other people. It’s thanks to those moments that I’ve used to reinvent myself, I’ve been able to achieve long-lasting fulfillment.

I know I’m starting to sound meta and all that corny stuff, but I decide to still leave it here as I’ve met people who will get to feel the hope again while relate to my story. I’ve got good news for you though. Only the foreword contains so little substance.
Please feel free to use this book whatever way you like to. You can read it as a regular book in its entirety or using it as a reference handbook, with easy to navigate index which allows you to jump into specific questions and answers.

Almost nothing worthwhile comes without pain or some sort of suffering so I’ve came to the point where I accept my mistakes and allow myself to live without blaming myself too much for making them. I advise you to look at things similar way, because holding to the past in which we weren’t as smart and wise brings nothing good. Looking at the future as a blank page, allows you to approach things differently and avoid repeating the old mistakes.
In the book, I”ll be guiding you through subjects that are very subjective and focus mostly on emotional intelligence and social skills, which can’t be as accurately measured. So you might feel like I’m yet another bozo, but you need to open your mind to fully benefit from it. I promise you that nothing in this book hasn’t been thoroughly tested, and each and every single chapter you find in this book describes lessons learnt from mistakes I’ve made personally in my career. I’m never talking about others, about things I’ve only read or heard about. Everything has been battled tested by yours truly and I believe most of it can be easily replicated into most working environments. It worked for me with minor contextual adjustments while working for companies from various countries on two continents with organisations ranging from a small services startups from Silicon Valley, through public institutions in Poland, to hundreds million dollars big corporations.

You need to sacrifice the present for the better future, but it doesn’t mean you need to sacrifice as much as I’ve had to. I’ve learnt a ton and I want to use that knowledge to help you make your professional life easier. I want you to be more effective and productive than I used to be all those years before I started taking the human aspect more seriously.

Understanding these concepts can potentially enable you to see a bigger picture and gain richer point of view. Please bear in mind that nothing is set in stone and that my experiences may be different from the things you’ve had a chance to experience in your career. So to limit the amount of anxiety and misunderstanding, let’s create a healthy narrative for this journey of ours. I want this book to be an inspiration for you, showing you yet another perspective of someone who gotten his hands dirty, not a predefined set of rules one must follow.  Use it as a doof for thought, a content for consumption and a spark to initiate something bigger and adjusted to the to culture of your organization and your personality. Your personality matters. Just because something had worked for me and is indeed a sane way to do things, doesn’t mean you’ll want to follow the same path. Things that come to me easily now may come hard to you, and that’s all fine. We are different, so embrace what’s best in you and use that to achieve what you want to.

How to squeeze maximum value out of invested time in reading this book

This book isn’t an ideal picture of the world. It never intended to be. It was meant to show us ways in which we can be more practical and effective. To show you how we can abandon the fears, imposter syndromes, anxiety and stress – or at least reduce it significantly, by small tweaks in a way we operate on daily basis. I want this book to be practical, so I recommend you to read this book slowly and don’t rush into next chapters. Please read a chapter and give yourself some space to reflect on it. Try to remind yourself a situation to which a chapter would apply and outline counterarguments to what I’ve written. Then find a right balance for you and find the best way for you to navigate through life. I’m not right, and you’re not wrong. We’re both doing our best, and sometimes the best solution is in the middle of two perspectives, of two totally different individuals. You do you.
After all while we’re expected to bring value to the business and help it make more money so if you’re still employed, then apparently you must be doing something right! However, regardless of how much we like or dislike our job currently, we can make ourselves like it more. We can make others like us more and we can reduce the anxiety of a whole system.
But for that to happen, we must improve our social skills, especially communication skills at scale.

I believe that security professionals can’t achieve their greatness at the workplace, if they’re not being actively supported by all stakeholders across the entire organization and if other employees don’t feel ownership for the organization’s safety. Security just must one of the core values of corporate culture. Each time I have joined an organization, where security professionals wanted to do everything themselves, they miserably and painfully failed shortly after.  Fighting a broken security culture without any support from the top leads to burnouts for InfoSec folks and creates general anxiety, irritation and a toxic atmosphere within an organization. No one wants that to happen, yet so often we end up in exactly such situation.

Right, but what about Secure SDLC you may ask? To me Secure SDLC is more technology centric, while DevSecOps is more human and culture centric. I may even write a book on secure SDLC one day, but we have a lot of great content on that matter already, so it’s not a priority by any means. To me, helping people understand the DevSecOps culture is much more important task, although they are very powerful couple, and I believe in the long run, one cannot exist without the other. I would even say that many companies have magnificent SSDLC, but it could be so much better if the operators understood that each business, is a human business first and you can boost whatever you’re doing by involving more people and making them care about it.
I’ve met many people who understand how to implement SSDLC principles into their organisations, however not many know how to build the DevSecOps culture which can bring their SSDLC or whatever they’re doing on the totally next level.
I’ve spent over 5 years working on implementing DevSecOps culture at the organisations I’ve worked at, because I believed that with so limited resources doing things together is the only way to go. We all hit a point in which we can’t scale anymore, which is why we must seek help of others. And to get such help, it’s good to provide it first. Be the leader people will happily look up to and many doors will open. And by working all together we can do much more and do it much better.
SSDLC is fabulous piece of art, and I wish more companies adopted it since 2002 when Microsoft officially announced it. I really with, because we’d be in a completely different shape as the whole industry. But we haven’t so we must add something to it, that will fill the gaps with a work that doesn’t cost much every single one of us. Collaboration and empathy is something that’s not that complicated or expensive if we only decide to take one step forward each and every single day.
With a right attitude the culture is something that can be created in the background, while we can use our technical competence to enhance our SSDLC workflows and incrementally improve resilience of the organisations we work for.

I hope the lessons shared in this book will save you – and everyone around you – a lot of anxiety and trouble. I wish I had access to such a resource when I was starting out, which I believe could’ve helped me prevent the damage that has happened otherwise. It’s never too late to learn and improve, so I’m still extremely grateful for an opportunity to have experienced so many things and that now I can share it for benefit of others. I hope this book helps you navigate through social interactions with lower stress and more fruitful results and although this book summarizes the most important lessons learnt over the past decade, I’ll be still happy if it saves you a single day of your life.  

Let’s get started already! 🙂

QA Summer Fest #1 – Miquido

Miquido,  fantastyczni ludzie, fantastyczna organizacja I mega atrakcyjne biuro!
Na wewnętrzne zaproszenie miałem przyjemność występować na pierwszym wydarzeniu z serii QA Summer Fest, więc nijako jestem z tego dumny 🙂
Spotkałem się z niesamowicie przyjaznym przywitaniem oraz pożegnaniem, wobec czego jeśli kiedykolwiek usłyszę “Miquido”, będę mieć tylko i wyłącznie dobre wspomnienia.
Sala konferencyjna była dostępna już na godzinę przed pierwszą prelekcją,  dzięki czemu każdy mógł się komfortowo przywitać i znaleźć sobie przyjemne miejsce do brania udziału w wydarzeniu. Ciężko było mi dostrzec choć jednej osoby, która by się nudziła, mimo, że przyznaję się bez bicia – przeciągnąłem swoją prelekcję mocno. I trochę za mocno i wiem, że uczestników wymęczyłem, jednak “connection” które czułem z grupą, sprawiło że prelekcja przemieniła się w przyjazną rozmowę na tematy życia codziennego w branży IT.
4 października po raz kolejny będę miał szansę spotkać się z ekipą Miquido w ramach mojej prelekcji na Mobiconf. Coś pięknego, dzięki jeszcze raz za gościnę!
Podrzucam jeszcze link do prezentacji, o który parę osób pytało: