 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Half of all open source contributors are never encouraged to use digital signatures when making changes to the open source projects they’re involved with according to the “2020 FOSS Contributor Survey.” In contrast, 17% are typically required to use a digital signature on all commits. Slightly more projects require cryptographic proof of somebody’s identity before the final package that is being released.
Especially in light of the recent SolarWinds attack, requiring digital certificates is a strong way to track open source code’s chain of custody throughout the software supply chain.
Requiring a digital signature can be a barrier for contributions because of the time and effort required to implement the system. If an open source project only has a few contributors, it may not seem worth the effort. Yet, 48% of projects also do not require the use of two-factor authentication (e.g., Google Authenticator or SMS messages) to accept a change request. Without this commonly used security approach, stolen or lost passwords can easily be used to hack a system.
Since 2004 developer certificate of origins (DCOs) have been a way to give a project legal permission to use a developer’s intellectual property, but their value as a way to increase trust among community participants has rarely been highlighted. In fact, when asked about the importance of DCOs, a third of contributors didn’t even know what they were, let alone if they were useful.
These approaches demonstrate attempts to secure the code repository platform itself and the user actions within it, but there are countless other attack surfaces in the CI/CD pipeline. Many times the need to identify code authorship is related to debugging and not security concerns.
Choosing a license and governing model are essential elements to making a project ready for prime time. Creating a code of conduct and contributing guide are important too but so are policies that promote security. However, only 26% of the maintainers or core participants said the projects they are involved with have a security policy in place. On a slightly more positive note, 41% of the respondents said that the projects have someone with a security focus. Let’s hope that every project will have a security champion going forward.
👁 Image
Feature image via Pixabay.
