Soteri Security for Jira allows for customizing which security rules are used for scanning in order to fit the needs of your organization.
To disable or enable a rule, first visit the Soteri Settings Page.
Only Jira administrators can access these settings.
Scanning rules are near the bottom of the page:
Each category of rules is expandable. You can enable and disable rules as required by clicking on each individual rule’s toggle.
Generic password filters
The GENERIC_PASSWORD rule expression captures passwords by context; this means the application looks for constructs like password: hunter2 or pw: letmein in order to identify the password in context. However, without configuring the rule, it produces a high number of false positives. For example:
user: admin
password: [REDACTED] // Would match - it follows "password:".
pw: <your password> // Would match.
pass: ******* // Would match.
password = sys.environ["PASSWORD"] // Would match.
pass: pass // Would match.
If the GENERIC_PASSWORD rule is enabled, you can tune false positive filters in order to ensure that these false positives do not match:
Automatic Filtering Options
Ignoring Environment Variable References
If you see false positives that are actually assignments to a field named “password” from an environment variable, you can enable this automatic filter. A list of false positives that would be filtered follow:
# Env var references:
password=%(db_password)s
password={secret}
password={{DB_PASS}}
password=#db_pass#
password=@db_pass@
password=<password>
password=:password
password=$(DB_PASS)
password=$DB_PASSWORD
password=${db_password}
password=$HOME/.secrets/pass
# Code-level env lookups:
password=os.environ['SECRET']
password=System.getenv("DB_PASS")
password=process.env.DB_PASSWORD
password=ENV["DB_PASSWORD"]
password=$_ENV['PASS']
password=env::var("SECRET")
password=GetEnvironmentVariable("PASS")
Ignoring Placeholder Values
False-positives with “placeholder” values are frustrating to see, but you can filter them automatically:
# Exact well-known tokens:
password=CHANGEME
password=CHANGE_ME
password=YOUR_PASSWORD_HERE
password=your-password-here
password=INSERT_PASSWORD
password=PLACEHOLDER
password=TODO
password=FIXME
password=EXAMPLE
password=SAMPLE
password=DEMO
password=TEMP
password=REPLACE_ME
password=example_password
password=sample_pass
# Noun + qualifier combos:
password=mypassword
password=yourpassword
password=mypasswordhere
password=testpassword
password=demopassword
password=db_password
password=adminpassword
password=defaultpassword
password=newpassword
password=oldpassword
password=passwordvalue
password=passwordgoeshere
password=passwordstring
password=mysecret
password=yoursecret
password=testsecret
# Substring matches (anywhere in the literal):
password=this_is_a_placeholder_value
password=changeme_later
password=your_password_goes_here
password=insert_your_secret_here
password=example_password_123
password=sample_pass_here
password=replace_me_with_real_pass
password=dummy_credential
password=notarealsecret
password=fake_password
password=todo_set_real_pass
Ignoring Null and Redacted Values
Sometimes passwords are initialized to empty, null, or otherwise benign values. Additionally, they may have been redacted before being inserted. Both of these cases are false positives that can be automatically filtered:
# Null-like:
password=None
password=null
password=undefined
password=N/A
password=""
password=''
password=
# Redaction markers:
password=*
password=****
password=********
password=[REDACTED]
password=[HIDDEN]
password=[MASKED]
password=REDACTED
password=HIDDEN
password=MASKED
password=xxxx
password=xxxxxxxx
Ignoring Values That Are Too Short
This exclusion has the highest likelihood of producing false negatives, because there are many short passwords that are nonetheless still passwords. To counteract that, this rule includes short passwords from the PWDB top 1000 most popular passwords:
# Filtered (< 6 chars, not a known weak password):
password=abc
password=xy
password=no
password=1234 ← only 4 chars, not in common passwords list
# NOT filtered — flagged despite being short, because they are known weak passwords:
password=admin ← 5 chars, in common passwords list
password=12345 ← 5 chars, in common passwords list
password=hello ← 5 chars, in common passwords list
password=pass ← 4 chars, in common passwords list
password=test ← 4 chars, in common passwords list
password=angel ← 5 chars, in common passwords list
password=james ← 5 chars, in common passwords list
password=jesus ← 5 chars, in common passwords list
Custom Patterns
If you have variable assignments or redaction patterns not anticipated by the automated filtering above, you can add new patterns in the custom patterns fields:
Some examples follow:
# Custom placeholders scenario - other languages (DE/FR/ES)
/(?i)((IHR_)?PASSWORT(_HIER)?)|BEISPIEL|PLATZHALTER|((VOTRE_)?MOT_DE_PASSE(_ICI)?)|
EXEMPLE|(([TS]U_)?CONTRASEÑA(_AQUI))|EJEMPLO/
# pass = IHR_PASSWORT
# pw = EXEMPLE
# pass: CONTRASEÑA_AQUI
# Custom redaction scenario - other languages (DE/FR/ES)
/(?i)GESCHWÄRZT|ZENSIERT|CENSURÉ|EXPURGÉ|REDACTADO|CENSURADO/
# pass = [GESCHWÄRZT]
# pass = [EXPURGÉ]
# pw: [censurado]
Email filters
If the EMAIL_ADDRESS rule is turned on, there are further settings that can be adjusted to fine tune what is detected.
Ignore role-based emails: Filter out email addresses based on role
-
abuse@
-
admin@
-
billing@
-
compliance@
-
contact@
-
feedback@
-
help@
-
hostmaster@
-
info@
-
legal@
-
marketing@
-
noc@
-
no-reply@
-
noreply@
-
postmaster@
-
privacy@
-
root@
-
sales@
-
security@
-
spam@
-
support@
-
sysadmin@
-
tech@
-
unsubscribe@
-
webmaster@
Ignore example and test emails: Filter out email addresses that are clearly examples or test emails.
-
@*.example
-
@*.invalid
-
@*.localhost
-
@*.test
-
@example.com
-
@example.net
-
@example.org
-
bar@
-
demo@
-
example@
-
foo@
-
sample@
-
test@
-
user@
Domain filtering: Optionally ignore a list of domains or only include that list of domains