Are you uncomfortable with open source security? You are not alone. According to a recent survey
by Open SSF, 41% of organizations out of more than 500 surveyed said they don't have high
confidence in the security of open source software they use. Security is a big topic, but there are
ways to understand it and gain confidence about it. I view it as three interconnected angles --
or what I call the triple A's of open source security considerations: Assess, Adopt, and Act.
You can view them from any order, but let's look at the Assess first. Under Assess, there are two main
things. First one is the assessment of project health. If you're not happy about project health,
you won't be happy about the security. So first, look at the project health. Look at the license
and governance. A healthy project should have a clear information about the license and there should
be an open governance. Also, look at the community and the current state of development. Look at the
open pull requests, look at the open issues. See how timely they are being addressed. Also, look
at the merge pull requests and see the quality of reviews and what kind of codes [changes] are being merged.
This will tell a lot about the project health. You can check mark it and move to the assessment
of security. Under security there are a few things. First one is studying the architecture and
security model. Also checking out the use cases and see the ease of use of software securely.
Second thing is the code review. Review the code with your security team. Let us review things
like how user access management is being done. How about data validations? And file
permission handling? If there are anywhere they are logging confidential information.
You ought to look at the test coverage for the security functionalities.
Third thing is understanding their security policies. A good project should have well
documented security policies about how to report an issue, how they handle CVEs.
How they do periodic improvements in the security postures and things like that.
The first thing is to understand the dependencies. A good project should have maintainers looking at
any new dependencies and studying them. But you also should study the dependencies yourself.
If the project has provided a software bill of material or SBOM, look at it. If it's not there,
you can create one using third-party tools as well. SBOM provides an inventory of dependencies
and transitory dependencies that can help you understand your risk related to dependencies.
Check mark it. The second aspect is Adopt. Adopting in-house policies for
these security considerations. Have policies around who will own the software internally. How
we will be reporting issues to the upstream project. Consider a situation when any of
those issues are not being addressed by the project team on time as you wanted.
What will be your plan there? Also think about version upgrade policies. Are there versions just
coming out? Maybe part of security fixes, maybe a major release. You want to have policies to upgrade
your version to keep at least to a level where the version is supported so that you can get help.
Then, overall you need to have policies for the risk management.
The next aspect is Act. To act upon the maintaining and improving the security
of open source. The security aspect is not only responsibilities of the
communities and the maintainers -- it should be also responsibilities of users. You can
contribute to the project in many ways: with the code, with the documentation, review of code.
Issue management -- anyone be part of user group and be active there. By contributing, you're not
only making the software better that you use and helping the community, but you are also staying
on top of the security and overall development of the project. Thanks for watching. If you want
to see more videos like this in the future, please like and subscribe.