Having a single call to mktemp (or any of the other related functions) anywhere in the codebase will mean that none of the calls to tmpnam (or any of the other related functions) will raise an alert. Is that really what you want?

You're right.
but I always try to reduce the number of false positives.
if there are no calls at all, this is definitely an error.

but if you think otherwise, I'll add broader rules

Reducing the number of false positives is a great goal! See my comment here regarding this. You don't have to fix it, but I think it might be valuable to revisit this condition and make it more precise (if you feel like it).

Like above: Any call to umask (or the other related functions) anywhere in the codebase means that this query won't raise an alert. Is that the intention?

You're right.
but I always try to reduce the number of false positives.
if there are no calls at all, this is definitely an error.

but if you think otherwise, I'll add broader rules

Reducing the number of false positives is good. This code could lead to missing a lot of genuine results, though. It could also potentially lead to a false sense of security. Let's say I had a bunch of genuine security issues found by this query. Suddenly, I add a call to umask that is totally unrelated to the security issues (for instance, I started to use umask in some unit test). Now all the genuine security vulnerabilities won't be flagged anymore.

One simple fix is to require that the call to umask (or the related functions) is in the same function as the call to open (or the related functions). Although you may also be able to connect the two calls better by using local dataflow.

this is a very difficult question for me.

your example of a sense of false security.
firstly, if the developer is using the wrong mask, we will also inform him that everything is fine. (especially if the mask will not be calculated trivially)
Secondly, if he uses a permission call far enough from the investigated place, we also cannot understand whether he wanted to extend these permissions to all calls or only to one distant one.

this is a very difficult question for me.

in my first requests to you, I believed that an experimental request should draw the attention of developers to possible problems, even having false positives (after all, if the developer decided to use experimental ones, he wants to see his code wider). but I realized that it is better to show a narrower problem, more precisely than a broader one with false positives (here I am operating on your assessment rules).

I'm not sure I understand what this description is saying. Can you rewrite it to better explain:

1. What this query is looking for
2. Why the results are problematic

I'm looking for situations where a file can be replaced (including using a temporary link) and influence third-party files on behalf of the program, as well as situations where it is possible to access (including the ability to change data) to files.

what do you think about
Finding for predictable, spoofed filenames before you start working on the file.

Why is a spoofed filename problematic? I was thinking about something along the lines of:

Using a predictable filename when creating a temporary file can lead to an attacker-controlled input.

Does something like that capture the spirit of your query?

Yes, you are right.
but the predictable filename is vulnerable for several reasons.
1.if you create a file with a symbolic link to another file you can cause it to be deleted or corrupted (accessibility)
2. If rights are broad, information can be accessed (confidentiality)
3.If it is possible to write, change the content (integrity)

all this is achievable and important. but in my opinion the most common use of attackers is 1. so I wanted to focus on it.
but your suggestion is absolutely correct, and if you think it fits better, I will insert it.

Thanks.