Koniec roku 2021 przyniósł branży IT spory chaos. Spowodowany był on luką bezpieczeństwa popularnej biblioteki Apache Log4j. W zależności od organizacji było to mniej lub bardziej odczuwalne. Software house’y odczuły problem dotkliwie przez kilka czynników:
- mnogość oraz różnorodność projektów,
- różnorodne stacki technologiczne,
- różny stopień zaawansowania projektów (od dopiero co się rozpoczynając, po będące jedynie w utrzymaniu od dłuższego czasu),
- czy też rotacje pracowników (zarówno wewnątrz organizacji, jak i na zewnątrz).
Mierzyły się zatem z bardzo złożonym problemem. Problem wynikał zarówno z bezpośredniego używania wspomnianej biblioteki, jak i również z faktu, iż wiele open source narzędzi, powszechnie używanych w codziennej pracy, Log4j miało jako swoją zależność.
Z podobnym wyzwaniem zmierzył się także mój zespół. Po wstępnej analizie kodu nie stwierdziliśmy nigdzie użycia Log4j. gwałtownie się jednak okazało, iż nasza analiza nie była w pełni poprawna, w dużej mierze właśnie ze względu na używane narzędzia open source.
Moja prezentacja to typowe lessons learned. Na przykładzie rozwijanej przez mój zespół aplikacji pokazuję:
- Jak nie przeprowadzać analizy kodu i na co zwrócić uwagę przy jej wykonywaniu,
- Jakie konsekwencje (pozytywne oraz negatywne) niesie używanie narzędzi open source i czego to wymaga od użytkowników (programistów),
- Jak minusy jednego narzędzia przekuć w zalety drugiego.
👉 [FB] https://www.facebook.com/4Developers
👉 [LI] https://www.linkedin.com/showcase/4developers
👉 [TT] https://twitter.com/4Developers