Speed vs. Risk Effective Software Security Doesn’t Choose

The rising number of sophisticated ransomware attacks has forced companies to consider shifting security left. Making security an intrinsic part of your SDLC shouldn’t slow things down. In fact, if you integrate security and development in the right way, you should be able to speed everything up. For example, security defects will be detected early on, developers will be able to run their own penetration tests, and the security team will always have an open communication channel with the developers. But, developing a healthy relationship between development and security teams is not always straightforward.

The security-development relationship

During the discussion, attendees were asked to comment on the relationship between development and security teams in their organizations. A CIO started by saying that they have set up a dedicated team to kick off the DevOps journey and are trying to integrate security more into their development practices. A senior executive added that even though they have security controls integrated into their CI/CD pipelines, they are still struggling to move security to the start of their SDLC. A VP told the audience that they don’t let people push insecure code and ensure that people adhere to their secure coding policy by performing periodic audits, code reviews, and vulnerability scans. Lastly, a director shared that they are exploring ways to use data analysis and machine learning to make informed decisions regarding cybersecurity.

Establishing a delicate balance between speed and risk

Multiple participants agreed that security measures shouldn’t slow down the speed. In today’s competitive market, it’s important to strike a balance between security and risk. A business must be capable of promptly catering to changing market dynamics while keeping real-world risks in mind. However, this can sometimes be hard to achieve. For example, a security team may hold up a release if they detect a potentially exploitable flaw in the code. However, this may not resonate with the business team, who wanted the release shipped out yesterday.

Communication is key

An executive talked about the importance of having open communication between security and development teams. Security engineers should educate developers regarding common and high-priority security risks and action items. Developers should, in turn, seek the security team's approval before installing a third-party/open-source package. Moreover, both teams should be capable of executing penetration tests, performing static code analysis, and identifying potential security flaws. You can’t shift security to the absolute left without enabling seamless collaboration between security and development teams.

Things to remember while starting your security journey

A speaker remarked that building an inventory should be the first step of the security journey. Create a list of applications, resources, and environments that you need to protect, and go from there. Without a proper inventory, you will often not know what you are up against. The next step would be to slowly start your threat modeling and find your security champions, i.e., people passionate about security and can be your change advocates. If you can get the managers, scrum masters, and architects on board early on, they can act as the perfect medium to deliver the message to a broader audience.

Security action items vs. feature requests

An attendee shared with the group that it can be hard to prioritize security items over feature requests in a sprint cycle, especially if the security items get added to an active sprint. If developers are asked to resolve a major security hotspot during a sprint, they may not have enough time to deliver an urgent feature to the business team. A solution can be to reserve some time for security fixes at the start of every sprint. Moreover, if any security-related items are expected in the near future, the security team should inform the scrum master beforehand.

The board is getting interested

Various speakers agreed that boards are now taking a deeper interest in cybersecurity. The main reason for this is the rising real-world incidents, media coverage, and financial losses. There was a time when organizations considered themselves “prepared” if they had cybersecurity insurance, but that is no longer enough. You need to take real security measures, make real investments into tooling and audits, and transform your culture (and workforce) to be more security-centric.

‍