This message was deleted.
# security
s
This message was deleted.
j
Very individualized to each company, but having a secure platform is important to the degree that it matters to the business - I would first look at the data / impact of a breach and cost of the security controls (in direct costs, opportunity cost, and maintenance/overhead). There's obviously a lot more to it though
Highly recommend doing a threat modeling activity to see what would go wrong, and then see what the opportunities are to make those attacks less likely. Then you can decide if it's worth it
y
Thank you so much Jon! When you say important to the business - who makes that decision? If you could build threat modeling and prioritization into your IDP would you?
j
I'm making a lot of assumptions with this response, but here goes. Usually I see product leadership having a big part in the conversation, for the products that run on the platform. You also may have a platform "asset owner" but they can't make the decision in a vacuum and their "interested parties" are usually the product & dev teams. Maybe also SREs, DevOps teams, etc. - depends on your org chart Threat modeling can be included as a part of grooming tasks, especially epics. That's usually my preference. If that's too much overhead, you could do it on a cadence - quarterly, yearly, etc. + as needed. Or anywhere in-between
y
So would a platform team be interested in a platform that scales application security (from code to cloud to code) or would someone else (like AppSec) have to care first.
I’m doing a little market research. Someone described us as Platform Engineering for Scaling AppSec … and no one here had ever heard about Platform Engineering. But when I started to explore it - it seems to me to be an audience we ignored - but shouldn’t. My only questions is whether they are solely motivated by the same thing developers are motivated by - release fast. Or do they take specs for a lot of teams including Appsec teams
j
Are you familiar with the CNCF cloud native security white paper? We covered some of these concepts in there fairly well. Here's the latest version, but a v3 is WIP. Specifically I would point to the TOC on page 3 and things like separating Develop, Distribute, Deploy, and Runtime. AppSec probably cares about all of those, especially if they "own" supply chain security. But platform really focuses on Runtime, and may depend on artifacts from prior stages (like signatures, attestations, etc.). Then there are other areas like Assurance / Compliance which care about Platform, and AppSec may be Responsible for parts of, but you may also have a GRC team Accountable for that part.
For instance - Platform shouldn't be Responsible for SAST, DAST, SCA, etc. That's AppSec (which may be distributed into the dev teams, or centralized - separate topic). However, the Platform team may decide to require certain artifacts (attestations; via in-toto or similar) regarding those controls before allowing them to be deployed/run.
y
Thanks so much - I will take a look. So the real internal customer for platform teams is the developer and not necessarily application security. If I understand you correctly
j
Typically, yeah - or at least the primary customer
Although I would love to hear if anyone else in the channel disagrees :)
y
Hey @Yael Citro - in my experience AppSec might need to care first, but platform engineering would be a great vehicle to delivery security at scale. AppSec may set the requirements, but platform can help make sure every new project / repo / pipeline lives up to them
y
@Yishai Beeri So Platform doesn’t set IDP product specs? I thought they had a Product owner on their team
y
Probably so, but when you need external expertise, this can come from appsec
y
Thanks @Yishai Beeri