What will be the Best Path for Storing .txt Files in SecOps Environment for Custom IDE?

[skadav]

I’m working on a project in a custom IDE and need to store a .txt file that’s being used in the development process. I wanted to check if there’s any specific path or location recommended for storing such files within a SecOps environment.

I tried saving the file without specifying a path, and while it worked initially, the file was automatically deleted after a few days.

Has anyone encountered this before, or is there a best practice for storing files like these in a SecOps environment to ensure they remain persistent?

Any advice would be appreciated!

Thanks in advance!

[TDRez]

The file system on the Python environment is designed to wipe itself, you can store the file to a case as an attachment or you could utilize a global context value for the same purpose if a string would suffice to store the file

[SoarAndy]

+1 to TDRez

How big is the file, and what is in it?  structured/unstructured/lookup tables... etc

[skadav]

The file will be incremental. It will only have file names (strings) and it will be in simple text, where each file will in new line.

[skadav]

Is there any option to store file on SOAR Remote Agent and use with IDE?

[SoarAndy]

Though you might be able to create something to do this, I recommend against it.  This would NOT be supported by the platform and any changes to the Agent in the future might change the way we work and thus break this approach.  

[SoarAndy]

If it's incrementing, have you looked at Custom Lists ?

You can populate/manage through GIT, and we have OOTB Actions to use in a playbook, and doesn't require a file system (which isn't really best practise)

[ashnaiku]

Yes. String Reference Lists seems to be the right fit here 
https://cloud.google.com/chronicle/docs/reference/reference-lists#string_reference_lists

[skadav · Accepted solution]

I got answer for it form Support case. Due to architecture, we cant save any txt file in IDE. I ended up storing file in S3 bucket itself. 
Thanks all for helping with multiple workarounds.