Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.
Secure Development Takes a (Remote) Village
The shift to work from home isn't just about giving your Dev team the physical tools they need.
5 Min Read
Development is a collaborative process. Yes, it requires stretches of focused time to create, but all developers heavily depend on their teammates to help plan the right solution, build the different components in it, and review any changes made. Furthermore, the development team needs to collaborate with the rest of the business to make sure its creation achieves the outcomes they all aim for.
This collaboration has been shaken up by the full-time remote work forced upon practically all developers as a result of COVID-19. Some teams are better equipped to handle it than others, but few are truly immune to the change. The complete absence of in-person whiteboard sessions, hallway conversations, and friendly chats by the coffee machine means we now have to adapt how we work together to create and deliver great software.
Security is at an even greater risk of being ignored. For starters, risk is naturally invisible, making it all too easy to overlook it. Secondly, the practices of secure development are still being formed, and now require more careful hand-holding. Last, the collaboration between development and security teams is often not great in normal times. Today, collaboration can easily worsen now.
What's needed? We must make a concentrated effort to secure development while working from home. Below are five best practices that both dev and security teams should adopt:
Practice 1: Empower developers to build with security front of mind.
To encourage developers to build with a security-first mindset, they first need to understand what good looks like and what is expected of them when it comes to cybersecurity. The best way to do this is to provide developers with comprehensive guidelines for security processes. This will allow them to move items forward without having to stop and wait for approval. Empowering developers with such responsibility will help them to feel more confident that they're ultimately building fully secure applications because they asked the right questions along the way.
Practice 2: Invest in security visibility
You can't empower developers to embrace security without giving them visibility into the critical vulnerabilities. Here are a few ways to do that:
Build a detailed software bill of materials (SBOM) for each application so your dev team knows if any newly disclosed vulnerabilities will affect their in-progress projects.
Raise awareness of vulnerabilities discovered in builds that weren't severe enough to break it to the full team — either in Slack or an equivalent internal communications channel — so you can avoid repeat mistakes across teams.
Create leaderboards showing how well different teams are handling security issues. This is a fun way to stoke competition while learning from each other.
Practice 3: Instead of breaking the build, fail pull requests.
Breaking the build due to a security violation is a popular CI/CD security measure, but it's also disruptive. This is especially true when working remotely as it takes that much longer to figure out the problem and get it resolved. Instead, fail pull requests — this has several advantages including:
They allow you to test only the new code changes, which should be within the developer's control to fix.
They're more local to the branch where code is modified, empowering developers, and maintaining individual autonomy.
You can choose whether a fail pull request blocks a merge or is just informational, again allowing developers to make their own judgement calls.
Practice 4: Partner up!
To help remote developers know whom to turn to when they have a security question, match up individuals from security teams with a dev person and vice versa. Building these one-on-one relationships will create a stronger overall rapport between the two functions.
Practice 5: Focus on security basics first.
It can seem counterintuitive, but when it comes to security, prioritize the basics before the esoteric attacks. Scaling how well you handle vulnerable components, configuration mistakes, and leaked tokens should take priority. Once your remote dev teams have ticked these boxes, they'll be better equipped to tackle more involved, multifaceted security challenges as they emerge.
Practice 6: Improve SSH security.
As more machines go remote, the risk of a developer machine getting compromised is higher. These dev machines often have access to sensitive systems, such as source code repositories or production systems they can SSH into. These three steps can help to more effectively secure those channels to mitigate potential damage:
Enable mutual key-based authentication.
Enable or reduce session timeouts.
Enable stronger identity-based authentication.
Practice 7: Bug Bounties
Bug bounties are a good way to add an extra layer of security assessment capability. Check out Bugcrowd or HackerOne —they can guide you through much of the process of setting up your own program if desired.
The shift to remote work isn't just about making sure members of your team have the physical tools they need to work away from the office. It's about recreating the positive aspects of an office environment so that developers can achieve great results by collaborating with their chosen "village."
Related Content:
About the Author
You May Also Like
More Insights
