Nowe wersje aplikacji są zazwyczaj wydawane w sposób ciągły. Powody wydania mogą obejmować wprowadzenie nowych funkcji, zmiany kodu w celu obsługi nowych platform lub wersji jądra, wykorzystanie nowych kontroli bezpieczeństwa w czasie kompilacji, takich jak kanarki lub Control Flow Guard (CFG), oraz naprawę luk w zabezpieczeniach. Często nowa wersja może zawierać kombinację wyżej wymienionych powodów. Im więcej zmian w kodzie aplikacji, tym trudniej zidentyfikować te związane z załataną luką w zabezpieczeniach. Duża część sukcesu w identyfikowaniu zmian kodu związanych z poprawkami luk w zabezpieczeniach zależy od ograniczonych ujawnień. Wiele organizacji decyduje się na ujawnienie minimalnych informacji na temat charakteru poprawki bezpieczeństwa. Im więcej wskazówek możemy uzyskać z tych informacji, tym większe prawdopodobieństwo, że odkryjemy lukę w zabezpieczeniach. Jeśli ogłoszenie o ujawnieniu stwierdza, że istnieje luka w zabezpieczeniach obsługi i przetwarzania plików JPEG, a my zidentyfikujemy zmienioną funkcję o nazwie RenderJpegHeaderType, możemy wnioskować, że jest ona związana z poprawką. Tego typu wskazówki zostaną pokazane w rzeczywistych scenariuszach w
dalszej części. Prosty przykład fragmentu kodu C, który zawiera lukę w zabezpieczeniach, jest pokazany tutaj:
A oto poprawiony kod
Problem z pierwszym fragmentem kodu polega na użyciu funkcji gets(), która nie oferuje sprawdzania granic, co skutkuje możliwością przepełnienia bufora. W poprawionym kodzie użyto funkcji fgets(), która wymaga argumentu rozmiaru, co pomaga zapobiec przepełnieniu bufora. Funkcja fgets() jest uważana za przestarzałą i prawdopodobnie nie jest najlepszym wyborem ze względu na niezdolność do prawidłowego obsługiwania bajtów null, takich jak dane binarne; jednak jest lepszym wyborem niż gets(), jeśli jest używana prawidłowo. Przyjrzymy się temu prostemu przykładowi później, używając narzędzia do porównywania binarnego.