If you failed to code your web application to comply with (newly) requested or required cybersecurity standards like NIST 800-218, NIST 800-171/CMMC, ISO 27001, HIPAA, GDPR, HITRUST, etc., you could find yourself painfully retrofitting controls where they’re not designed to go. This is a big reason why it’s so critical to shift DevSecOps left into the earliest phases of the software development lifecycle (SDLC).
For example, a number of IoT ecosystem vendors that did not account for California’s SB 327 legislation now have installed bases of tens of thousands of devices that are out of compliance with no practical way to update them. This potentially puts the vendor or its customers at risk for sanctions from the California Attorney General.
Prove you’re secure
André Keartland, Solutions Architect at Netsurit, explains: “A lot of the time, the security standards or goals that you’re trying to meet are not necessarily those of your organization. Especially if you’re writing software for other people, you have to be ready [for compliance requirements].”
You may also need to be ready to produce a software bill of materials (SBOM) to account for your third-party libraries. Or deliver a guarantee/attestation based on credible application security testing that your solution won’t introduce unacceptable security risks into a customer’s environment. Or demonstrate to a cyber liability insurance carrier that your software development environment and process is secure.
André adds: “A lot of our customers are big banks, and they’ve become very, very, very gun-shy because they’ve realized a lot of the time when they lose data it’s not thei ..
Support the originator by clicking the read the rest link below.
