Luki w oprogramowaniu są tak stare jak samo oprogramowanie. Mówiąc najprościej, luki w oprogramowaniu to słabość w projektowaniu lub wdrażaniu oprogramowania, która może zostać wykorzystana przez osobę atakującą. Należy zauważyć, że nie wszystkie błędy są lukami w zabezpieczeniach. Błędy od luk odróżniamy za pomocą współczynnika możliwości wykorzystania. W 2015 roku Synopsys przygotował raport, który pokazał wyniki analizy 10 miliardów linii kodu. Badanie wykazało, że kod komercyjny miał 0,61 defektów (błędów) na 1000 linii kodu (LoC), podczas gdy oprogramowanie open source miało 0,76 defektów (błędów) na 1000 LoC. Jednak to samo badanie wykazało, że kod komercyjny radził sobie lepiej w porównaniu ze standardami branżowymi, takimi jak OWASP Top 10.5. Ponadto wykazano, że 1–5 procent defektów oprogramowania okazuje się lukami w zabezpieczeniach. Ponieważ współczesne aplikacje powszechnie mają licznik LoC wśród setek tysięcy, jeśli nie milionów, typowa aplikacja może zawierać dziesiątki luk w zabezpieczeniach. Jedno jest pewne: tak długo jak ludzie będą tworzyć oprogramowanie, będziemy mieć luki w zabezpieczeniach. Co więcej, dopóki mamy luki w zabezpieczeniach, użytkownicy są zagrożeni. Dlatego też na specjalistach i badaczach ds. bezpieczeństwa spoczywa obowiązek zapobiegania, znajdowania i naprawiania tych luk, zanim osoba atakująca je wykorzysta, wyrządzając szkodę użytkownikowi. To ostateczna misja hakera w szarym kapeluszu. Podczas ujawniania luk w zabezpieczeniach pojawia się wiele kwestii. Dla hakera oznacza to szczegółowe informacje, takie jak to, z kim się skontaktować, jak się z nim skontaktować, jakie informacje podać i jak zapewnić odpowiedzialność wszystkich stron za ujawnienie. W przypadku dostawcy obejmuje to szczegółowe informacje, takie jak śledzenie raportów o lukach w zabezpieczeniach, przeprowadzanie analizy ryzyka, uzyskiwanie odpowiednich informacji do wprowadzenia poprawki, przeprowadzanie analizy kosztów i korzyści związanych z programowaniem mającym na celu wprowadzenie poprawki oraz zarządzanie komunikacją z konsumentami i osobą, która zgłosił lukę. Kiedy cele związane z tymi rozważaniami nie są zbieżne między hakerem a dostawcą, istnieje możliwość tarć. Pojawiają się kluczowe pytania, np. ile czasu wystarczy dostawcy na wprowadzenie poprawki? Czy haker i sprzedawca zgadzają się, że poprawka jest ważna? Czy osoba, która w dobrej wierze zgłasza lukę w zabezpieczeniach, powinna otrzymać odszkodowanie lub zostać rozpoznana? Jak długo klienci powinni zapewnić sobie bezpieczeństwo, instalując łatkę, zanim haker lub sprzedawca opublikuje szczegółowe informacje na temat luki? Jaka ilość szczegółów jest odpowiednia? Czy klienci zastosują łatkę, jeśli nie zrozumieją niebezpieczeństwa niezastosowania łatki? Odpowiedzi na wszystkie te pytania często są przedmiotem gorących sporów. Niektórzy badacze mogą uznać nieujawnianie informacji za nieujawnione, jeśli sprzedawca zdecyduje się nie podejmować działań w związku z luką. Utrzymujące się zagrożenie dla konsumentów w obliczu utrzymującej się luki w zabezpieczeniach może być frustrujące, gdy nie ma innego organu, który mógłby pociągnąć dostawcę do odpowiedzialności za bezpieczeństwo. Jednak nawet dostawcy dbający o bezpieczeństwo mogą działać zgodnie z wymaganiami wielu badaczy, budżetów, menedżerów produktów, konsumentów i inwestorów, co wymaga ponownego zrównoważenia priorytetów, co nie zawsze zadowala każdego badacza. W tych kwestiach nie ma formalnego konsensusu. Typowe metody ujawniania obejmują pełne ujawnienie dostawcy, pełne ujawnienie publiczne i ujawnienie skoordynowane. W duchu etycznego hakowania skłaniamy się ku koncepcji skoordynowanego ujawniania informacji; mamy jednak nadzieję, że przedstawiliśmy opcje w przekonujący sposób i pozwolimy Tobie, czytelniku, podjąć decyzję.
UWAGA: terminy te są kontrowersyjne i niektórzy mogą preferować „częściowe ujawnienie dostawcy” jako opcję postępowania w przypadkach, gdy kod potwierdzający koncepcję (POC) jest ukrywany i gdy w proces ujawniania zaangażowane są inne strony. Aby było to proste, w tej książce będziemy trzymać się powyższych terminów.