Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Are secured variables really secure?

I know that tje value of these variable are hidden on the pipeline‘s output.

But I could see those values with this trick below:


- step:


      - echo $VAR >> var.txt


      - var.txt

You can see the value on var.txt file.


I want to use workspace variable for saving workspace access token, to reference it on a pipeline for accessing API, but because of this vulnerability I hesitate.



1 answer

1 accepted

0 votes
Answer accepted
Theodora Boudale
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Mar 22, 2023

Hi @남성식 and welcome to the community!

If you make a variable secured, its value will be masked in the build log. Pipelines masks all occurrences of a secure variable's value in your log files (the variable name will show instead), regardless of how that output was generated.

However, both workspace and repository variables can be retrieved by any user that has write access to the repo where the build is running.

You could use deployment variables instead and if your workspace is on the Premium plan, you can restrict deployments to admins only. This way, only users with admin access could use the script from your post to retrieve the deployment's variable value; users with write access only won't be able to do that.

You can check the following links for more details about deployment variables and deployment permissions:

Kind regards,

Great answer. Thx!

Because my team has several projects and these have all different permissions.

If they have workspace token, it violates our access permission rule.

Then should I share the workspace token with all project leaders and let them save it as deploy variable for all repositories?

I hope that we have project-level variable but I know it's now there.

Would you please let me know what's the best way to handle it?

Moreover, the application password of a project owner, which is saved as a repo-variable, could be seen by other developers. Then the other people can acquire his access right. It is also dangerous situation, isn't it? Is this the reason why we should prefer using access tokens than using app-password?

One more question!

With access token, people can access API without leaving information who they are, I think. Because of access token we could make CI run without any personal information, but it's more dangerous than personal password, isn't it?

Patrik S
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Mar 28, 2023

Hello @남성식 ,

Secure variables are exposed as environment variables in each pipeline step, so essentially anyone who can edit your pipelines can access the variable. Saving the variable to an artifact is only one way of accessing them, it's really hard to stop users from exporting the variables if they have to write access to the pipeline. As mentioned earlier by @Theodora Boudale , a way of restricting access to variables is by defining them in a deployment environment, so you can limit just admins to be able to change the script code and export those variables. 

Another option to increase security is when creating your workspace access tokens, use the principle of least privilege, and select only the scopes that are strictly necessary for the API endpoints you are calling. This should limit the operations of the APIs that can be executed with the access token.

As for whether to use app passwords or access tokens, this really depends on your see case. As you mentioned, app passwords are attached to a user account and have the same access as the account where they were created, but are limited to the scopes that were selected during its creation. On the other hand, workspace/project/repository access tokens don't represent a particular user and are generally used for tasks such as scripting and CI/CD tools. 

Thank you, @남성식 !

Patrik S

Like 남성식 likes this

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events