See for yourself – run a scan on your code right now

Walk, Talk and Act like your internal customers: Product Engineering

In my previous role at Nielsen, Clay Carter and Sam Neely did a phenomenal job of organizing the Product Security function into what closely resembles an engineering function. Product Managers oversaw services built internally and off the shelf. These services go through release planning, sprints and some use CI/CD pipelines.

Beyond the day-to-day service delivery activities, an internal customer advisory board was stood up that communicated new release information, shared the roadmap and discussed tough issues that created friction between security and engineering.

Now in my current role, I see several of our clients already operating this way or headed quickly in this direction.

Adopt the process

To become an engineering function, you need to act like one. Adopt the best practices from modern software engineering so you refactor your security team’s processes and culture to mimic that of your engineering teams.

  • Adopt Agile & DevOps to organize your work and create consistent feedback loops
  • Conduct release planning. Ideally with your engineering counterparts. Make service roadmaps available to your stakeholder community.
  • Deliver in sprints. Track Burndown, Velocity, Escaped defects.
  • Ensure that the Security’s SDLC, Security Tooling and CI/CD pipelines are identical to the experience of their counterparts in Product Engineering. No shortcuts – it has to be the same.
  • Consider hiring a talented scrum master without security experience. It’s amazing how seamless the transition can be with the right leaders.
  • Implement an internal customer advisory board to increase trust and transparency and to create your bi-directional feedback loop.
  • If you have a Security Champions program, they’re already bought in. They should participate but should be the only engineering representatives.
  • Make sure your toughest detractors are offered to participate. I have often found that critics are right as much as they’re wrong. If they’re right, fix it. If they’re wrong, use an evidence based approach to bring them onboard.
  • Meet regularly but only with a value-add agenda. Don’t waste anyone’s time. What needs to be communicated, what feedback is needed and what decisions need to be made?
  • Track and show back progress.

This is post two in a series of articles by our CISO, Chris Hatter, discussing topics of relevance from his experience in the CISO chair. Part one, from last week, was the 1st installment of this discussion.

About ShiftLeft

ShiftLeft empowers developers and AppSec teams to dramatically reduce risk by quickly finding and fixing the vulnerabilities most likely to reach their applications and ignoring reported vulnerabilities that pose little risk. Industry-leading accuracy allows developers to focus on security fixes that matter and improve code velocity while enabling AppSec engineers to shift security left.

A unified code security platform, ShiftLeft CORE scans for attack context across custom code, APIs, OSS, containers, internal microservices, and first-party business logic by combining results of the company’s and Intelligent Software Composition Analysis (SCA). Using its unique graph database that combines code attributes and analyzes actual attack paths based on real application architecture, ShiftLeft then provides detailed guidance on risk remediation within existing development workflows and tooling. Teams that use ShiftLeft ship more secure code, faster. Backed by SYN Ventures, Bain Capital Ventures, Blackstone, Mayfield, Thomvest Ventures, and SineWave Ventures, ShiftLeft is based in Santa Clara, California. For information, visit:


See for yourself – run a scan on your code right now