So you’ve decided to hire an application security engineer? Here’s what you need to know

Hiring your first appsec engineer is a high-risk endeavor.

Many organizations reach the conclusion they need to hire an appsec engineer after accumulating years – if not decades – of application security debt. Hiring an appsec engineer can be a long process, and for many organizations, is one that does not end successfully. This is important to point out because there’s an opportunity cost associated with waiting to address application security until you’ve brought on a dedicated resource. But even worse than not making any appsec hire is making the wrong appsec hire. A bad appsec hire can create a false sense of security for business owners, while also aggravating software engineers and alienating them from security as an engineering practice.

Appsec hiring is challenging because demand is high and talent is scarce.

We have a few clients who dream about hiring “appsec unicorns.” An appsec unicorn is someone who not only understands appsec fundamentals, but they also know how to write code, function as a member of a software engineering team, and can communicate effectively with all stakeholders in an engineering organization: software engineers, product managers, executives, and information security/risk managers. These unicorns not only fix tactical security bugs on their own, but they also act as leaders who increase the security engineering capabilities of the organization.

Appsec unicorns want to be part of a winning team, and they don’t like inefficiency.

I’ll be blunt: appsec unicorns don’t want to feel hamstrung by corporate bureaucracy, they get above market salaries, and they don’t want to waste time on a commute. If your organization does not have a progressive, modern approach to business and software engineering, you will have trouble recruiting and retaining not only a unicorn, but a capable appsec engineer. If you hire a good appsec engineer and expect them to commute 2 hours a day, every day, you can expect to have retention challenges due to the number of remote work opportunities available for great appsec people.

Do not rely on security certifications to help identify a good appsec engineer.

“Well, this person is a CISSP, and they’re the best candidate we have right now, so let’s hire them.” Widely accepted information security certificates are not a great indicator of success for an appsec role. Additionally, technical penetration testing certifications (such as OCSP or CREST) may be a better indicator of appsec fundamentals, but don’t indicate if a person can productively collaborate with software engineering teams. Putting a great penetration tester into an appsec role in an engineering organization more often creates conflict, rather than progress. This often happens due to a mismatch in perceived criticality of security issues. A pen tester may find what he or she believes to be a “critical” security bug, while engineering doesn’t believe it’s a security bug at all! Too often, the pen tester is exaggerating the criticality rating, and while engineering may be forced to begrudgingly fix whatever the issue is, more damage has been done to the team than risk actually reduced for the organization. What looks like a tactical win for security is actually a long term loss because engineering loses respect for the appsec engineer.

One engineer might not be enough; you might need an appsec team.

Appsec unicorns, aka the single person appsec team, are hard to find, hire, and retain. To compensate, be prepared to design and build an application security team. For example:

  • Application Security Director: reports to CTO/SVP; peers with VP of Eng/Product; works with the business and technology leaders to understand the business direction, and create a supporting appsec strategy
  • Security Architect: reports to appsec director; works with software architects to identify security assumptions and prescribe architectural security controls; advocates for security in the engineering organization
  • Security Engineer 1: focused on building/implementing re-usable security code and features, for example: secure APIs, authentication/authorization controls, encryption code & utilities
  • Security Engineer 2: focused purely on vulnerability identification and remediation through code review, internal penetration testing, and third party penetration testing
  • Security Engineer 3: focused purely on security infrastructure (not infrastructure security) to automate detection and remediation for classes of security vulnerabilities; includes internal tool development and evaluation/acquisition of commercial and open source security tooling 

An application security program with strong leadership will have an impact that outlasts any single appsec hire.

Even at great companies, employees come and go. For long term application security assurance, you need an appsec program that is bigger than any single person. Long term success starts with making security a strategic priority for your software engineering organization. Bringing in a strong security leader with software engineering experience will shift the perception of security across engineering teams, and start them down the path of building purposefully secure applications and systems. A limited number of appsec engineers can be more effective when the bulk of your software engineering org is capable of handling low-hanging fruit security bugs themselves.

Do you want an application security program that reduces risk and security-friction in your engineering organization? Reach out and let’s have a conversation.

Article Link: https://carvesystems.com/news/hiring-an-appsec-engineer-what-you-need-to-know/