Incorporating 'secure by design' into the software supply chain [Q&A]
Developers historically have not been all that security savvy, but as software supply chain security becomes a larger and larger problem every day, enterprises are going to need to secure packages before they are put into production environments.
We spoke to Phylum CEO, Aaron Bray, to learn more about 'secure by design' and how it can make sure developers are being taught security as part of their development and training process and are also being provided with the necessary resources to code securely from the beginning.
BN: What makes software secure by design and why is it so important?
AB: Great question -- being 'secure by design' means ensuring that security is a core part of the design philosophy applied at each stage of the development process, from architecture to implementation. This includes applying basic security principles, such as least privilege and zero trust, at each decision point. This is important for many reasons, from being able to achieve regulatory compliance (where required) to ensuring that your attack surface is minimized. Additionally, it means making secure the default configuration and permitting deviations from that only by exception.
BN: Does this apply at a project level or across the organization?
AB: Really it should be both -- and in many cases, you won't be able to have one without the other. At the project level, engineers, architects, and project managers need to think carefully about the security implications of the decisions they make, how users interact with the project, how the project will interact with other systems, and what types of risks might be associated with a breach or compromise (i.e., does the system process PII? Company confidential information? Etc.). At the organization level, this concept is important for every portion of the organization that has any responsibility for system design and implementation – who has access to what information, what roles should they have, etc. In short, it needs to fundamentally be part of the business culture in order to ensure that such practices are applied and followed throughout the organization.
BN: How does this fit in with government guidelines like the CISA and NCSC Secure design principles?
AB: Such guidelines are a great starting point -- they help organizations understand what they should focus on to start thinking the right way, and can help steer the internal development culture in the right direction. That said, such documents tend to be pretty high level, and there will be some additional work to be done to ensure that individual contributors understand how such concepts apply to their day-to-day tasks.
BN: How big a role does training play in implementing secure by design?
AB: A huge one -- one of the big challenges organizations have historically faced in achieving these sorts of principles is that many of the individuals involved in the process may not be security experts, and thus, may have a poor understanding of what things they even need to be concerned with from a security perspective. Understanding, at a minimum, the fundamentals and the biggest risks your part of the process may pose is very important. This is true whether we're discussing a cloud engineer who is implementing network and routing configurations, or a developer writing software to interface with a database.
BN: What can organizations do to ensure the principles are followed across their software supply chain?
AB: A great place to start (beyond the fundamentals outlined within the high-level guidelines) is to consider both the security posture of internal assets and external assets. For internal assets, conventional application security controls, regular code reviews, and external audits for critical systems are a good way to help mitigate risks. Some emerging frameworks, such as SLSA, can also be good to consider for some of these assets -- while they still have their flaws, such frameworks can help organizations understand and track what internal components are being used where, and how they were generated. External assets, on the other hand, tend to be primarily open source for most organizations. In these cases, consider emerging maturity models, such as the S2C2F in order to ensure that your utilization of these types of libraries is secure. For these types of assets, it is ultimately important to strive to establish both mechanisms to not only manage traditional software vulnerabilities, but ultimately to set guidelines, principles, and policies about what your development teams are allowed to use, to ensure that no architectural issues or accidental compromises occur up front.
Image credit: serezniy/depositphotos.com