Security used to be the responsibility of a dedicated team in the last development stage, but with development cycles increasing in number and speed, security practices need to be constantly updated.
This has led to the rise of DevSecOps, which emphasizes security within DevOps. Companies need DevSecOps to make sure their initiatives run safely and securely. Without DevSecOps, DevOps teams need to rebuild and update all their systems when a vulnerability is found, wasting time and effort.
[ Want a primer? Read also: Why DevSecOps matters to IT leaders. ]
Here are four key considerations for leaders as they begin to implement DevSecOps:
1. Understand your company’s security policies and standards so that security components can be chosen wisely at development time
Proper security and audit policy are such that you should be able to prove that what is expected to be in production is in fact what ends up there at runtime. Being able to verify what you’re running in production shouldn’t need special code to be added to the original code, which would thereby save retesting and maintaining new code. In fact, if this verification could happen at runtime and offer instant reporting on what’s running across all your applications, then your team would have the proof and oversight it had been lacking: proof of security, governance, and compliance.
[ Read also: DevSecOps: 7 habits of strong security organizations. ]
2. Implement build environments that are static, reproducible, and immutable
By creating builds with systematic, repeatable build processes across the organization, teams will be able to reduce vulnerabilities and ensure application quality. Implement an organization-wide process for how open source language builds are resolved for dependencies, licenses, and security. This will eliminate time lost to retrofitting, bake in security, and increase agility.
Trusted and curated language distributions can enable these benefits across the entire team and construct the three lifecycle stages of open source languages: build, certify, and resolve.
3. Be proactive
Identify license compliance and vulnerability considerations during the development process, not after. Knowing the components you have in your application and scaling this component knowledge across your entire application portfolio, combined with keeping track of those updates, is a tremendous effort. This can be effectively automated to establish an understanding of a team’s reliance on, and the risk related to, individual components.
This approach enables teams to keep security goals front and center and maintain continuous delivery as they are automatically notified of updates to open source components.
All third-party open source components should be scanned for license compliance and vulnerabilities. An application’s risk evolves over time, making it necessary to monitor open source packages for vulnerabilities, datedness, and licensing from development throughout the software development lifecycle, including the CI/CD processes and into production.
[ Need a primer on continuous integration/continuous delivery? Read What is CI/CD? ]
Previously, tracking security across the SDLC and into production involves installing some continuously running agent, either at the system level using application scanning tools (AST) or within the application’s code using runtime application self-protection (RASP) solutions.
Today, agentless monitoring through interpreter plugins enables security to be deployed right at the source code so that security teams can keep pace with development and products get to market faster. This approach provides greater visibility into security across compliance, InfoSec, and risk management teams.
[ Are you speaking the wrong language? See How to talk to normal people about security. ]
4. Use the latest versions of components – from projects that are actively maintained, where possible
Open source software that is outdated or poorly maintained can provide exploitable attack vectors for bad actors and destabilize your mission-critical application. Many open source packages are created by multiple contributors and may not go through a strict security review process. Moreover, even if packages have gone through a security assessment in the past, they may contain new vulnerabilities not yet known. And these new vulnerabilities will not be detected by existing tools and processes.
To address these issues, organizations should enforce policies to prevent the use of vulnerable packages, modules, and libraries; maintain an up-to-date inventory of packages used by applications; and perform regular checks for vulnerabilities based on trusted sources of information. If any of the packages are found to contain a vulnerability, patches must be applied and new versions deployed.
A new security opportunity
It isn’t entirely up to the developer to implement DevSecOps standards within the organization. However, it is the role of the developer to create a security standard during development. Why not go above and beyond the bare minimum — license compliance, vulnerability checking, component checks — and establish a stronger security standard using available tools and processes? DevSecOps offers the opportunity to save time, frustration, and rework while increasing security and time to market.
[ Making security a shared responsibility across the whole team isn’t easy. Read also: DevSecOps: 7 ways to address cultural challenges. ]
