Skip to main content
Question

How to handle passwords in response actions

  • February 13, 2026
  • 5 replies
  • 63 views
_eo
Forum|alt.badge.img+5

Hey everyone,

I’m trying to get some best practices around handling passwords in actions when importing playbooks into SecOps platforms. Here is my situation. We deploy playbooks to multiple SecOps tenants and when we import that playbooks, passwords used by actions (S1 Download threat file for example) doesn’t keep the password originally used. I understand the reasoning behind this, but having to manually re-enter the password in to every action that uses it is hassle and not all actions allow for placeholders within the password value field.

5 replies

cmorris
Staff
Forum|alt.badge.img+11
  • cmorris
  • Staff
  • February 13, 2026

Have you tried Gitsync - https://medium.com/google-cloud/response-as-code-in-google-secops-engineering-the-modern-soc-e6731930b3b9?

Be aware of the password settings and concerns though - https://docs.cloud.google.com/chronicle/docs/soar/marketplace/power-ups/gitsync#known-issues-and-limitations

_eo
Forum|alt.badge.img+5
  • _eoBronze 4
  • Author
  • Bronze 4
  • February 13, 2026

We have tested GitSync and it works really well but there are underlying issues with the SecOps platform that prevent us from using it. Hoping this can be resolved with Google support.I saw the secops toolkit earlier and will use it as inspiration for future plans. 

 

The issue with passwords not being synced is the ultimate issue. I understand the security concerns for that. Just looking for away around that. If there isn’t, that is fine.

AnimSparrow
Forum|alt.badge.img+5
  • AnimSparrowBronze 2
  • Bronze 2
  • February 21, 2026

Hello! I’m not sure if this will help, as it depends on the specific actions you are using.

However, you can create a Custom Integration and define multiple password fields within its configuration. If you then update your Custom IDE actions to reference those fields, you’ll only need to maintain the credentials in one central place.

Of course, this approach won't work if you are strictly using pre-built integrations that cannot be modified.

_eo
Forum|alt.badge.img+5
  • _eoBronze 4
  • Author
  • Bronze 4
  • February 23, 2026

Hello! I’m not sure if this will help, as it depends on the specific actions you are using.

However, you can create a Custom Integration and define multiple password fields within its configuration. If you then update your Custom IDE actions to reference those fields, you’ll only need to maintain the credentials in one central place.

Of course, this approach won't work if you are strictly using pre-built integrations that cannot be modified.

that’s an interesting concept. You could potentially do the same and combine the two options? Custom integration with passwords and use those values and input fields for the pre-built integrations?

AnimSparrow
Forum|alt.badge.img+5
  • AnimSparrowBronze 2
  • Bronze 2
  • February 24, 2026

Hello! I’m not sure if this will help, as it depends on the specific actions you are using.

However, you can create a Custom Integration and define multiple password fields within its configuration. If you then update your Custom IDE actions to reference those fields, you’ll only need to maintain the credentials in one central place.

Of course, this approach won't work if you are strictly using pre-built integrations that cannot be modified.

that’s an interesting concept. You could potentially do the same and combine the two options? Custom integration with passwords and use those values and input fields for the pre-built integrations?

Honestly - hard to say :) But it would be worth to give it a try in free time to simply either get new feature or exclude it from potential solution.

Terms & ConditionsCookie settingsAccessibility statement
Privacy Policy Terms of Service Gen AI Policy Community Guidelines Cookie Settings

© 2025 Google. All rights reserved.