Despite the effort of software maintainers, patches to open-source repositories are propagated from the main codebase to all the related projects (e.g., forks) with a significant delay. Previous work shows that this is true also for security patches, which represents a critical problem. Vulnerability databases, such as the CVE database, were born to speed-up the application of critical patches; however, patches associated with CVE entries (i.e., CVE patches) are still applied with a delay, and some security fixes lack the corresponding CVE entries. Because of this, project maintainers could miss security patches when upgrading software.In this paper, we are the first to define safe patches (sps). An sp is a patch that does not disrupt the intended functionality of the program (on valid inputs), meaning that it can be applied with no testing; we argue that most security fixes fall into this category. Furthermore, we show a technique to identify sps, and implement SPIDER1, a tool based on such a technique that works by analyzing the source code of the original and patched versions of a file. We performed a large-scale evaluation on 341,767 patches from 32 large and popular source code repositories as well as on 809 CVE patches. Results show that SPIDER was able to identify 67,408 sps and that most of the CVE patches are sps. In addition, SPIDER identified 2,278 patches that fix vulnerabilities lacking a CVE; 229 of these are still unpatched in different vendor kernels, which can be considered as potential unfixed vulnerabilities.