The old adage “build vs. buy” doesn’t quite capture the full spectrum of decision-making in software development. A more accurate perspective considers the balance between what you build and what you purchase. Let’s examine the authentication component of “MyOwnTutorial” as an example to illustrate how this balance plays out.
A purely built solution entails designing the data storage, implementing all authentication mechanisms (passwords, multi-factor authentication, passkeys, etc.), managing the hashing and salting of passwords, generating tokens, and incorporating other features and nuances such as logging and geo-blocking.
Conversely, a pure purchase solution involves companies considering an all-in-one solution like Okta. However, this approach isn’t entirely hands-off, as integration and potentially some coding are necessary to provide developer teams with a means to interface with the third-party service. This method offers some flexibility, should there be a change in the underlying vendor.
A third option is a blend of the two, utilizing a solution like Keycloak, which manages some but not all features. This approach can expedite delivery and mitigate risk.
Security must be a consideration in each scenario, functioning either as an enabler or as a gate.
Build: Custom Authentication Solution
Security as a Gate: Developing a custom authentication system allows “MyOwnTutorial” to precisely tailor security to its unique needs. However, this route poses significant challenges, particularly in ensuring the system’s resilience against evolving threats. Acting as a gatekeeper, security demands thorough expertise and resources to validate the system against industry standards, compliance, and vulnerability testing. This scenario necessitates extensive threat modeling, security testing, and adherence to stringent requirements.
Security as an Enabler: Alternatively, security can spearhead the development of the authentication system, serving as a vendor to the product team. This arrangement enables “MyOwnTutorial” to integrate with the authentication and authorization system akin to an external vendor. The advantage here is that the security team can employ the application security testing strategies it prefers, including threat models, static code analysis, and vulnerability assessments, while also managing implementation, documentation, and support.
Buy: Commercial Solutions like Okta
Security as a Gate: Opting for a solution like Okta simplifies the authentication process for “MyOwnTutorial.” In this role, security sets high standards for vendor selection, influenced by Okta’s security reputation, compliance, and support. However, dependency on a third-party vendor raises concerns about data sovereignty and customization limitations. Security assessments and audits may delay the purchasing process, with security still requiring threat models and secure integration practices before release.
Security as an Enabler: Security can facilitate the integration of Okta by addressing product team limitations and building a service that simplifies Okta integration. This involves taking charge of logging, secret management, and more, thereby working closely with product teams to provide integration documentation and support.
Blend: Integrating Open-Source Tools like Keycloak
Security as a Gate: A blended approach with Keycloak offers flexibility but requires vigilant integration to prevent vulnerabilities, particularly where custom code intersects with open-source components. Security mandates thorough threat modeling, up-to-date policies, and comprehensive planning to ensure security best practices are followed.
Security as an Enabler: In this model, security assumes responsibility for the Keycloak deployment and associated coding. Given authentication’s critical role in security (essential for confidentiality), the security team becomes the proprietor of the tools, code, documentation, and support, altering its interaction with the product team.
Though authentication might seem a straightforward area to differentiate between security as a gate and as an enabler, the distinction is not always clear. This principle applies across all stages of the software development lifecycle, particularly in aspects that affect the system’s confidentiality, integrity, and availability. By taking a hands-on approach, such as developing a logging library or optimizing event management systems, security shifts from being a gatekeeper to an enabler.
If security truly is everyone’s responsibility, then the security team must engage more deeply, moving beyond mere oversight to actively shaping and securing the development process.