This is a guest post by Tyler Booker, Director of Tego Advisory Services
With hundreds of organizations still recovering from the CrowdStrike and Microsoft outages last week, it’s important to understand what makes for a good Software Development Life Cycle (SDLC) program when discussing software updates. In general, most organizations never consider the “what if” regarding supply chain risk, which is apparent when we perform our risk assessments for organizations.
There is a general lack of vendor management that evaluates third-party security programs, so many issues are simply missed when they could be identified with simple inquiries or requirements placed on them. Through our framework-based assessments, we’ve identified common gaps in vendor management and internal SDLC practices. Here, we share actionable tips to help organizations ask the right questions when searching for partners with well-developed systems or when strengthening their internal SDLC programs. While it’s impossible to eliminate all risks, these tips can help reduce the likelihood of incidents and mitigate their impact overall.
Proper Testing
Testing should always happen with any software update that occurs. Some organizations think just reviewing the code is enough to get them by and ensure no problems. That cannot continue to be the case. Depending on the type of software, proper testing should include user acceptance testing and testing of the software on systems to ensure proper functionality. Not every update will have significant code changes, but that is not the point. Even a minor update to code can have far-reaching impacts, and inadequate testing could fully affect those impacts on the software users.
Production, Dev, and Test
Cost is always a factor when building out an SDLC environment. Having separate dev, test, and production environments can be costly. That’s understandable, but we want to ensure that providing the product to users is no longer an option because it is cost-prohibitive. Segmenting your environments so updates don’t get pushed out to production is important in any SDLC. The environments should be separate to avoid major outages or security events like what we’ve seen with significant incidents in the past.
Proper Permission Policies in Environments
One aspect often overlooked is who should have access to those separate environments and rights to push code into each. With any application or system, roles and permissions should be limited to users authorized to perform the functions necessary for the job. Nothing more should be granted than that which is necessary for this. For example, your junior developer should not have permission to push the code he just finished writing to production. A senior developer should review and test it before final approval by another senior developer before it can be moved from dev to production.
Publishing Windows
When code is ready to be pushed, it should be done when staff are available to find bugs and work to fix them. Doing this over a weekend is not ideal as no one is available to resolve any potential issues.
Implementing the above recommendations can help organizations avoid a disaster like the one earlier this month. Contact us today for help implementing your SDLC program.